Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933592AbXHFUT4 (ORCPT ); Mon, 6 Aug 2007 16:19:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1764427AbXHFUT3 (ORCPT ); Mon, 6 Aug 2007 16:19:29 -0400 Received: from netops-testserver-3-out.sgi.com ([192.48.171.28]:59855 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1764200AbXHFUT1 (ORCPT ); Mon, 6 Aug 2007 16:19:27 -0400 Date: Mon, 6 Aug 2007 13:19:26 -0700 (PDT) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Matt Mackall cc: Daniel Phillips , Peter Zijlstra , linux-kernel@vger.kernel.org, linux-mm@kvack.org, David Miller , Andrew Morton , Daniel Phillips , Pekka Enberg , Lee Schermerhorn , Steve Dickson Subject: Re: [PATCH 02/10] mm: system wide ALLOC_NO_WATERMARK In-Reply-To: <20070806201257.GG11115@waste.org> Message-ID: References: <20070806102922.907530000@chello.nl> <200708061121.50351.phillips@phunq.net> <200708061148.43870.phillips@phunq.net> <20070806201257.GG11115@waste.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1391 Lines: 37 On Mon, 6 Aug 2007, Matt Mackall wrote: > > > Because a block device may have deadlocked here, leaving the system > > > unable to clean dirty memory, or unable to load executables over the > > > network for example. > > > > So this is a locking problem that has not been taken care of? > > No. > > It's very simple: > > 1) memory becomes full We do have limits to avoid memory getting too full. > 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 > > 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. The common solution is to have a reserve (min_free_kbytes). The problem with the network stack seems to be that the amount of reserve needed cannot be predicted accurately. The solution may be as simple as configuring the reserves right and avoid the unbounded memory allocations. That is possible if one would make sure that the network layer triggers reclaim once in a while. - 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/