Re: [patch 5/18] mark swapout pages PageWriteback()

[Andrew Morton <akpm@zip.com.au>]

Linus Torvalds wrote:
> 
> On Sun, 26 May 2002, Andrew Morton wrote:
> >
> > One fix would be to teach shrink_cache() to wait on PG_locked for swap
> > pages.  The other approach is to set both PG_locked and PG_writeback
> > for swap pages so they can be handled in the same manner as file-backed
> > pages in shrink_cache().
> 
> How about making them do exactly what normal writeout does, namely drop
> the locked bit too. Is there any advantage to holding it any more? The
> difference between swap writeout and normal writeout seems to be fairly
> arbitrary at this point.
> 

That leads to block_flushpage() being called under spinlock against a
page which has locked buffers, so it schedules on the buffer lock and
the box deadlocks.

So... can do, but I'll have to sort out the block_flushpage-under-spinlock
problem in the process.

But I recall you saying that there was advantage in keeping swapout pages
locked so that aggressive memory users would throttle against their
own swapout.  What's the story there?

Generally, there are a number of irritating swap special-cases popping up
and yes, it would be nice to give swap a proper inode, superblock (maybe)
and a get_block so it can become more regular.  One obstacle there is
the PAGE_SIZE versus PAGE_CACHE_SIZE thing.  Would have to add a new
address_space.page_size for that, which would penalise other address_spaces
slightly (in terms of memory usage and code size).

I've been trying to not look at the swap code ;) But there will be some
benefit it teaching swap to go direct to BIO to avoid the extra buffer
allocations when things are squeezy.  So I do need to stick my nose in 
there.

-