On Sun, 9 Dec 2001, Daniel Phillips wrote:
> The difference is, there's only one superblock per mount. There are
> bazillions of inodes.
.. and they share buffers.
I bet that having a pointer to the buffer will _reduce_ average
average footprint rather than increase it. The inodes are fairly densely
laid out in the buffers, so I dare you to find any real-world (or even
very contrieved) usage patterns where it ends up being problematic.
Remember: we'd save 15*4=60 bytes per inode, at the cost of pinning the
block the inode is in. But _usually_ we'd have those blocks in memory
anyway, especially if the inode gets touched (which dirties it, and
updates atime, which forces us to do writeback). For the initial IO we
obviously _have_ to have them in memory.
And we'll get rid of inodes under memory pressure too, so the pinning will
go away when memory is really tight. Yes, you can try to "attack" the
machine by trying to open all the right inodes, but the basic attack is
there already. ulimit is your friend.
> It's worth keeping in mind that tweaking the icache efficiency in this case
> is really just curing a symptom - the underlying problem is a mismatch
> between readdir order and inode order.
Well, the inode writeback read-modify-write synchronization and related
efficiency problems actually has nothing to do with the readdir order.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:14 EST