Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757060AbXHONzy (ORCPT ); Wed, 15 Aug 2007 09:55:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756875AbXHONzq (ORCPT ); Wed, 15 Aug 2007 09:55:46 -0400 Received: from viefep18-int.chello.at ([213.46.255.22]:59595 "EHLO viefep31-int.chello.at" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755110AbXHONzp (ORCPT ); Wed, 15 Aug 2007 09:55:45 -0400 Subject: Re: [RFC 0/3] Recursive reclaim (on __PF_MEMALLOC) From: Peter Zijlstra To: Andi Kleen Cc: Nick Piggin , Christoph Lameter , linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, dkegel@google.com, David Miller , Daniel Phillips In-Reply-To: References: <20070814142103.204771292@sgi.com> <20070815122253.GA15268@wotan.suse.de> <1187183526.6114.45.camel@twins> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-zbCJ4M02+eISTRzbDrdW" Date: Wed, 15 Aug 2007 15:55:20 +0200 Message-Id: <1187186120.6114.56.camel@twins> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2409 Lines: 67 --=-zbCJ4M02+eISTRzbDrdW Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2007-08-15 at 16:15 +0200, Andi Kleen wrote: > Peter Zijlstra writes: > >=20 > > Christoph's suggestion to set min_free_kbytes to 20% is ridiculous - no= r > > does it solve all deadlocks :-( >=20 > 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=20 > from free to easily reclaimable. I see that as an general improvement. >=20 > 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. --=-zbCJ4M02+eISTRzbDrdW Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGwwXIXA2jU0ANEf4RAh06AJ9tDH6os9rYP27C+XjdS0FmxIpo2QCeJRLs SuGkz9WLmIn91HJ+wnXl3XA= =JwOq -----END PGP SIGNATURE----- --=-zbCJ4M02+eISTRzbDrdW-- - 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/