Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763723AbXHVTF5 (ORCPT ); Wed, 22 Aug 2007 15:05:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1760356AbXHVTEy (ORCPT ); Wed, 22 Aug 2007 15:04:54 -0400 Received: from netops-testserver-3-out.sgi.com ([192.48.171.28]:42814 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1764974AbXHVTEw (ORCPT ); Wed, 22 Aug 2007 15:04:52 -0400 Date: Wed, 22 Aug 2007 12:04:51 -0700 (PDT) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Peter Zijlstra cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, riel Subject: Re: [RFC 0/7] Postphone reclaim laundry to write at high water marks In-Reply-To: <1187766156.6114.280.camel@twins> Message-ID: References: <20070820215040.937296148@sgi.com> <1187692586.6114.211.camel@twins> <1187730812.5463.12.camel@lappy> <1187734144.5463.35.camel@lappy> <1187766156.6114.280.camel@twins> 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: 1832 Lines: 42 On Wed, 22 Aug 2007, Peter Zijlstra wrote: > Its unavoidable, at some point it just happens. Also using reclaim > doesn't seem like the ideal way to get out of live-locks since reclaim > itself can live-lock on these large boxen. If reclaim can live lock then it needs to be fixed. > As shown, there are cases where there just isn't any memory to reclaim. > Please accept this. That is an extreme case that AFAIK we currently ignore and could be avoided with some effort. The initial PF_MEMALLOC patchset seems to be still enough to deal with your issues. > Also, by reclaiming memory and getting out of the tight spot you give > the rest of the system access to that memory, and it can be used for > other things than getting out of the tight spot. The rest of the system may have their own tights spots. Language the "the tight spot" sets up all sort of alarms over here since you seem to be thinking about a system doing a single task. The system may be handling multiple critical tasks on various devices that have various memory needs. So multiple critical spots can happen concurrently in multiple application contexts. > You really want a separate allocation state that allows only reclaim to > access memory. We have that with PF_MEMALLOC. > Also, failing a memory allocation isn't bad, why are you so worried > about that? It happens all the time. Its a performance impact and plainly does not make sense if there is reclaimable memory availble. The common action of the vm is to reclaim if there is a demand for memory. Now we suddenly abandon that approach? - 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/