Re: 2.5.50-bk5-wli-1

[Andrew Morton <akpm@digeo.com>]

William Lee Irwin III wrote:
> 
> William Lee Irwin III wrote:
> >> 2.5.50-wli-bk5-12 resize inode cache wait table -- 8 is too small
> 
> On Fri, Dec 06, 2002 at 12:24:07AM -0800, Andrew Morton wrote:
> > Heh.  I decided to make that really, really, really tiny in the expectation
> > that if it was _too_ small, someone would notice.
> > For what workload is the 8 too small, and what is the call path
> > of the waiters?
> > (If it is `tiobench 100000000' and the wait is in __writeback_single_inode(),
> > then we should probably just return from there if !sync and the inode is locked)
> 
> This is actually the result of quite a bit of handwaving; in the OOM-
> handling series of patches with the GFP_NOKILL business, I found that
> tasks would block exessively in wait_on_inode() (which was tiobench
> 16384).

Yup.  I haven't really considered or tested any other strategies
here, but it's part of writer throttling.  If we let these processes
skip an inode which is already under writeback and go on to the next
one there is a risk that we end up submitting IO all over the disk.

Or not.  I have not tried it.

All those threads would end up throttling in get_request_wait() instead.
Which is a single waitqueue.  But it is wake-one.

> The entire summary of results
> of that series of patches was "highmem drops dead under load".

There really is no shame in sending out bugreports, you know.

> But performance benefits from this minor increase in size should be obvious.
> 

But they're all waiting on the same inode ;)