Re: [PATCH] Re: Solaris 100K TCP connections, good example? was:[Fwd:

Chuck Lever (cel@monkey.org)
Wed, 29 Sep 1999 13:31:09 -0400 (EDT)

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/