Messages in this thread | | | Date | Tue, 28 Sep 1999 06:08:09 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: Solaris 100K TCP connections, good example? was:[Fwd: [Fwd: |
| |
On Tue, 28 Sep 1999, Alan Cox wrote:
> > in that case, every filesystem iget operation has to wade through 100K+ > > inodes to find an inode (imagine the length of the hash lists in a 256 > > bucket hash table!). every d_lookup has to do the same. each inode is as > > So dont use a 256 bucket hash table. Dave has some nice 2.2. patches for > the hashes (and the socket hashes want to be bigger too)
Alan, pardon me, but WTF do we need to include the socket inodes into the normal hash chains? Let's make a separate chain for them (out of the hash table) and be done with that. If we are doing iget() on _socket_ inodes anywhere we are indeed deep in it. Heck, they have NULL i_sb, just what will you pass to iget() to look for them? NULL is not a good idea - somehow I doubt that the the kernel will be happy with NULL->read_inode() in case of the cache miss.
ObThingsThatSuck: AFFS layout. Up to 5 (on-disk) list surgeries upon the rename(). In the bloody single-linked lists. Happy, happy, joy, joy... And we can't allow the thing to break in the middle - fs corruption and general unhappiness will follow. Damn, plain unlink may take 3 movements _and_ reshuffling of another sort of lists (also single-linked). The bloody thing is choke-full of metadata-corrupting races and I can't blame the authors of the driver. Now, authors of the _design_... What was the old UK punishment for high treason, again? Arrrgh... Down, not across. Al -- Two of my imaginary friends reproduced once ... with negative results. Ben <float@interport.net> in ASR
- 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/
| |