Re: [PATCH] modified segq for 2.5

Daniel Phillips
2002-09-10T01:50:43Z

On Tuesday 10 September 2002 00:58, Andrew Morton wrote:
> Daniel Phillips wrote:
> >
> > On Monday 09 September 2002 11:38, Andrew Morton wrote:
> > > One thing this patch did do was to speed up the initial untar of
> > > the kernel source - 50 seconds down to 25. That'll be due to not
> > > having so much dirt on the inactive list. The "nonblocking page
> > > reclaim" code (needs a better name...)
> >
> > Nonblocking kswapd, no? Perhaps 'kscand' would be a better name, now.
>
> Well, it blocks still. But it doesn't block on "this particular
> request queue" or on "that particular page ending IO". It
> blocks on "any queue putting back a write request". Which is
> basically equivalent to blocking on "a bunch of pages came clean".

It's not that far from being truly nonblocking, which would be a useful
property. Instead of calling ->writepage, just bump the page to the front of
the pdlist (getting deja vu here). Move locked pages off to a locked list
and let them rehabilitate themselves asynchronously (since we can now do lru
list moves inside interrupts). If necessary, fall back to scanning the
locked list for pages that slipped through the cracks, though it may be
possible to make things airtight so that never happens.

What other ways for kswapd to block are there? Buffers may be locked; a
similar strategy applies, which is one reason why buffer state should not be
opaque to the vfs. ->releasepage is a can of worms, at which I'm looking
suspiciously.

> Skipping is dumb. It shouldn't have been on that list in the
> first place.

Sure, it's not the only way to skin the cat. Anyway, skipping isn't so dumb
that we haven't been doing it for years.

--
Daniel