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

[Andrea Arcangeli <andrea@suse.de>]

On Sun, May 26, 2002 at 08:38:26PM -0700, Linus Torvalds wrote:
> 
> 
> On Sun, 26 May 2002, Andrew Morton wrote:
> >
> > 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?
> 
> The advantage is not the lock itself, as much as having people who page in
> swap pages be delayed on them - which ends up slowing down processes that
> swap a lot.
> 
> BUT: that could equally well be done by doing a "wait_on_writeback()" or
> similar, and it could also be a tunable thing (ie wait on writeback only
> when we actually need to slow them down). In particular, _not_ slowing
> them down does improve throughput, it just makes it really really nasty
> from an interactive standpoint under some loads.
> 
> I don't know. I have this feeling that it would be good to try to share
> all the semantics between swap pages and shared file mappings, but at the

that is definitely a good idea, that's why I resurrected in my current vm
patches your optimizations that allows a minor fault to be resolved even
if the swapcache is under async writeout.

The fact is that there is no difference at all between MAP_SHARED and
MAP_ANONYMOUS in terms of memory pressure, the only difference is that
with MAP_SHARED we are guaranteed that we won't run out of "swap" space.
No other differnece.

In short the same way MAP_ANON must pageout correctly, also MAP_SHARED
must swapout correctly with very vm intensive conditions.

I suggest not making differences in the algorithm (besides having to use
two different code paths, but in terms of mem pressure and minor faults
the actions should be the same, if not then one of the two is either
buggy or inferior).


> same time I also have to admit to believing that swap _is_ special in some
> ways, so if we don't ever really unify them I won't be shedding any huge
> tears.
> 
> 		Linus
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


Andrea