Re: [PATCH] adding per sb inode list to make invalidate_inodes() faster

[William Lee Irwin III <wli@holomorphy.com>]

William Lee Irwin III <wli@holomorphy.com> wrote:
>>  The only motive I'm aware of is for latency in the presence of things
>>  such as autofs. It's also worth noting that in the presence of things
>>  such as removable media umount is also much more common. I personally
>>  find this sufficiently compelling. Kirill may have additional ammunition.

On Thu, Sep 09, 2004 at 12:08:18PM -0700, Andrew Morton wrote:
> Well.  That's why I'm keeping the patch alive-but-unmerged.  Waiting to see
> who wants it.
> There are people who have large machines which are automounting hundreds of
> different NFS servers.  I'd certainly expect such a machine to experience
> ongoing umount glitches.  But no reports have yet been sighted by this
> little black duck.

Unfortunately all the scenarios I'm aware of where this is an ongoing
issue involve extremely downrev and vendor-centric kernel versions along
with the usual ultraconservative system administration, so this specific
concern is somewhat downplayed as other ongoing functional concerns
(e.g. direct IO on nfs breaking, deadlocks, getting zillions of fs's to
mount at all, etc.) have far higher priority than performance concerns.


William Lee Irwin III <wli@holomorphy.com> wrote:
>>  Also, the additional sizeof(struct list_head) is only a requirement
>>  while the global inode LRU is maintained. I believed it would have
>>  been beneficial to have localized the LRU to the sb also, which would
>>  have maintained sizeof(struct inode0 at parity with current mainline.

On Thu, Sep 09, 2004 at 12:08:18PM -0700, Andrew Morton wrote:
> Could be.  We would give each superblock its own shrinker callback and
> everything should balance out nicely (hah).

Hmm. My first leaning and implementation was to hierarchically LRU
inodes within sb's, but I suppose that's plausible. Let me know if you
want the shrinker callbacks or something else in particular done.


-- wli