Messages in this thread | | | Date | Wed, 29 Sep 1999 13:31:09 -0400 (EDT) | From | Chuck Lever <> | Subject | Re: [PATCH] Re: Solaris 100K TCP connections, good example? was:[Fwd: [Fwd: |
| |
On Tue, 28 Sep 1999, Alexander Viro wrote: > Look: there are very few functions that really scan the hash chains. > That is, iunique() and iget(). Both ignore the inodes with i_sb different > from their argument. Neither is called with sb==NULL, so from their point > of view the socket inodes are ballast. The rest couldn't care less which > chain inode belongs to (some do care whether it belongs to _some_ list, > though). So we have no reason for putting socket and pipe inodes into the > normal hash chains (ones anchored in inode_hashtable). > All we need to do is to modify insert_inode_hash() so that it > would put inodes with ->i_sb==NULL into separate chain. Callers don't need > to know about that - it's purely inode.c business. The patch follows:
alexander-
socket inodes are not inserted into the hash table. i stated this incorrectly yesterday. they are created with get_empty_inode(), and their i_sb field is initialized to NULL. insert_hash_table is never used to insert one of these into the inode hash.
they *are* however added to the inode_in_use list. this is the real problem, since this is the list that is scanned by free_inodes() to look for freeable inodes. a socket inode has a positive reference count throughout its lifetime, and the in_use list is linear.
free_inodes() walks the in_use list looking for inodes with a zero reference count. it's not clear to me how a zero reference count inode can get onto the in_use list, though. i would think that iput is careful enough to move inodes whose reference count goes to zero to the unused list. all other references to the i_count field in the kernel i can find are either reads or increments, except iput and iunique, which are decrements, and get_empty_inode and get_new_inode, which set i_count to 1.
- Chuck Lever -- corporate: <chuckl@netscape.com> personal: <chucklever@netscape.net> or <cel@monkey.org>
The Linux Scalability project: http://www.citi.umich.edu/projects/linux-scalability/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |