Re: [RFC 0/3] Recursive reclaim (on __PF_MEMALLOC)

[Peter Zijlstra <a.p.zijlstra@chello.nl>]

[-- Attachment #1: Type: text/plain, Size: 1734 bytes --]

On Wed, 2007-08-15 at 16:15 +0200, Andi Kleen wrote:
> Peter Zijlstra <a.p.zijlstra@chello.nl> writes:
> > 
> > Christoph's suggestion to set min_free_kbytes to 20% is ridiculous - nor
> > does it solve all deadlocks :-(
> 
> A minimum enforced reclaimable non dirty threshold wouldn't be
> that ridiculous though. So the memory could be used, just not
> for dirty data.

Sure, and note that various patches to such an effect have already been
posted (even one by myself), they introduce a third reclaim list on
which clean pages live. If you add to that a requirement to keep that
list at a certain level, one could replace part (or all) of the reserves
with that.

But that is more an optimisation rather than anything else.

The thing I strongly objected to was the 20%.

Also his approach misses the threshold - the extra condition needed to
break out of the various network deadlocks. There is no point that says
- ok, and now we're in trouble, drop anything non-critical. Without that
you'll always run into a wall.

> His patchkit essentially turns the GFP_ATOMIC requirements 
> from free to easily reclaimable. I see that as an general improvement.
> 
> I remember sct talked about this many years ago and it's still
> a good idea.

That is his second patch-set, and I do worry about the irq latency that
that will introduce. It very much has the potential to ruin everything
that cares about interactiveness or latency.

Hence my suggestion to look at threaded interrupts, in which case it
would only ruin the latency of the interrupt that does this, but does
not hold off other interrupts/processes. Granted PI would be nice to
ensure the threaded handler does eventually finish.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]