Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763643AbXHFU0p (ORCPT ); Mon, 6 Aug 2007 16:26:45 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1762992AbXHFU0i (ORCPT ); Mon, 6 Aug 2007 16:26:38 -0400 Received: from viefep18-int.chello.at ([213.46.255.22]:37368 "EHLO viefep20-int.chello.at" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1762832AbXHFU0g (ORCPT ); Mon, 6 Aug 2007 16:26:36 -0400 Subject: Re: [PATCH 02/10] mm: system wide ALLOC_NO_WATERMARK From: Peter Zijlstra To: Christoph Lameter Cc: Matt Mackall , Daniel Phillips , linux-kernel@vger.kernel.org, linux-mm@kvack.org, David Miller , Andrew Morton , Daniel Phillips , Pekka Enberg , Lee Schermerhorn , Steve Dickson In-Reply-To: References: <20070806102922.907530000@chello.nl> <200708061121.50351.phillips@phunq.net> <200708061148.43870.phillips@phunq.net> <20070806201257.GG11115@waste.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-j9ombzTnzJ7u0ISCI54Z" Date: Mon, 06 Aug 2007 22:26:32 +0200 Message-Id: <1186431992.7182.33.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: 2359 Lines: 73 --=-j9ombzTnzJ7u0ISCI54Z Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2007-08-06 at 13:19 -0700, Christoph Lameter wrote: > On Mon, 6 Aug 2007, Matt Mackall wrote: >=20 > > > > Because a block device may have deadlocked here, leaving the system= =20 > > > > unable to clean dirty memory, or unable to load executables over th= e=20 > > > > network for example. > > >=20 > > > So this is a locking problem that has not been taken care of? > >=20 > > No. > >=20 > > It's very simple: > >=20 > > 1) memory becomes full >=20 > We do have limits to avoid memory getting too full. >=20 > > 2) we try to free memory by paging or swapping > > 3) I/O requires a memory allocation which fails because memory is full > > 4) box dies because it's unable to dig itself out of OOM > >=20 > > Most I/O paths can deal with this by having a mempool for their I/O > > needs. For network I/O, this turns out to be prohibitively hard due to > > the complexity of the stack. >=20 > The common solution is to have a reserve (min_free_kbytes).=20 This patch set builds on that. Trouble with min_free_kbytes is the relative nature of ALLOC_HIGH and ALLOC_HARDER. > The problem=20 > with the network stack seems to be that the amount of reserve needed=20 > cannot be predicted accurately. >=20 > The solution may be as simple as configuring the reserves right and=20 > avoid the unbounded memory allocations.=20 Which is what the next series of patches will be doing. Please do look in detail at these networked swap patches I've been posting for the last year or so. > That is possible if one=20 > would make sure that the network layer triggers reclaim once in a=20 > while. This does not make sense, we cannot reclaim from reclaim. --=-j9ombzTnzJ7u0ISCI54Z 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) iD8DBQBGt4P4XA2jU0ANEf4RAvHDAJ4hcHpsFJPqLHGQMoQ1hCNYsYxC5ACfd6E3 ciEp6wvG+MRy3AItvJtVcLk= =nuNO -----END PGP SIGNATURE----- --=-j9ombzTnzJ7u0ISCI54Z-- - 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/