[PATCHSET 2.6.22-rc4-mm2] sysfs: make directory dentries/inodes reclaimable, take#2

From: Tejun Heo
Date: Wed Jun 13 2007 - 15:27:58 EST


This patchset makes directory dentries and inodes reclaimable and is
consisted of the following eleven patches.

#01: make-sysfs_drop_dentry-access-inodes-using-ilookup
#02: rename-sysfs_dirent-s_type-to-s_flags-and-make-room-for-flags
#03: implement-SYSFS_FLAG_REMOVED-flag
#04: implement-sysfs_find_dirent-and-sysfs_get_dirent
#05: make-kobj-point-to-sysfs_dirent-instead-of-dentry
#06: consolidate-sysfs-spinlocks
#07: use-sysfs_mutex-to-protect-the-sysfs_dirent-tree
#08: restructure-add-remove-paths-and-fix-inode-up
#09: move-sysfs_drop_dentry-to-dir.c-and-make-it-static
#10: implement-sysfs_get_dentry
#11: make-directory-dentries-and-inodes-reclaimable

API changes...

* kobj->dentry replaced with kobj->sd as dentry can go away
* shadowed directory handling functions now take sysfs_dirent instead
of dentry

Changes from the last take[L] are...

* #01 added.
* #02 and #03 splitted from the first patch of the last take.
* #06 added. sysfs_lock isn't used as global sysfs_dirent tree lock.
merge it with kobj_sysfs_assoc_lock.
* #07 modified to use sysfs_mutex instead of sysfs_lock to protect
sysfs_dirent tree. This resolves the problem Cornelia was seeing in
the last take.
* #08 and #09 added. This is primarily to keep the parent inode's
timestamps and i_nlink in sync. Code looks better after the change
too.

I'm running stress test for several hours now and things look pretty
good. This will save quite some amount of memory on big machines.

This patchset applies on top of 2.6.22-rc4-mm2 or

current linux-2.6#master (a0e1d1d075cc0efe9a3ac8579bce9393d070e09f)
+ regenerated sysfs rework patchset (forgot to cc lkml when posting.
the end result is practically the same to 2.6.22-rc4-mm2)

Thanks.

--
tejun

[L] http://thread.gmane.org/gmane.linux.kernel/535388


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/