Re: [2.4] heavy-load under swap space shortage

[Marcelo Tosatti]

On Sun, 14 Mar 2004, Andrew Morton wrote:

> Andrea Arcangeli <andrea@xxxxxxx> wrote:
> >
> > > 
> > > Having a magic knob is a weak solution: the majority of people who are
> > > affected by this problem won't know to turn it on.
> > 
> > that's why I turned it _on_ by default in my tree ;)
> 
> So maybe Marcelo should apply this patch, and also turn it on by default.

Hhhmm, not so easy I guess. What about the added overhead of 
lru_cache_add() for every anonymous page created? 

I bet this will cause problems for users which are happy with the current 
behaviour. Wont it?

Andrea, do you have any numbers (or at least estimates) for the added
overhead of instantly addition of anon pages to the LRU? That would be
cool to know.

> > There are workloads where adding anonymous pages to the lru is
> > suboptimal for both the vm (cache shrinking) and the fast path too
> > (lru_cache_add), not sure how 2.6 optimizes those bits, since with 2.6
> > you're forced to add those pages to the lru somehow and that implies
> > some form of locking.
> 
> Basically a bunch of tweeaks:
> 
> - Per-zone lru locks (which implicitly made them per-node)
> 
> - Adding/removing sixteen pages for one taking of the lock.
> 
> - Making the lock irq-safe (it had to be done for other reasons, but
>   reduced contention by 30% on 4-way due to not having a CPU wander off to
>   service an interrupt while holding a critical lock).
> 
> - In page reclaim, snip 32 pages off the lru completely and drop the
>   lock while we go off and process them.

Obviously we dont have, and dont want to, such things in 2.4.

Anyway, it seems this discussion is being productive. Glad!

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/