Date: Wed, 15 Aug 2007 13:32:03 -0700 (PDT)
From: Christoph Lameter <clameter@sgi.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
cc: Andi Kleen <andi@firstfloor.org>, Nick Piggin <npiggin@suse.de>,
       linux-mm@kvack.org, linux-kernel@vger.kernel.org,
       akpm@linux-foundation.org, dkegel@google.com,
       David Miller <davem@davemloft.net>,
       Daniel Phillips <phillips@google.com>
Subject: Re: [RFC 0/3] Recursive reclaim (on __PF_MEMALLOC)
In-Reply-To: <1187186120.6114.56.camel@twins>
Message-ID: <Pine.LNX.4.64.0708151330180.7326@schroedinger.engr.sgi.com>
References: <20070814142103.204771292@sgi.com>  <20070815122253.GA15268@wotan.suse.de>
 <1187183526.6114.45.camel@twins>  <p731we43muw.fsf@bingen.suse.de>
 <1187186120.6114.56.camel@twins>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1134
Lines: 28

On Wed, 15 Aug 2007, Peter Zijlstra wrote:

> The thing I strongly objected to was the 20%.

Well then set it to 10%. We have min_free_kbytes now and so we are used
to these limits.

> 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.

Networking?

> 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.

Where is the patchset introducing additional latencies? Most of the time 
it only saves and restores flags. We already enable and disable interrupts 
in the reclaim path but we assume that interupts are always enabled when 
we enter reclaim.

-
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/