Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936351AbXHHATI (ORCPT ); Tue, 7 Aug 2007 20:19:08 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1763161AbXHHASz (ORCPT ); Tue, 7 Aug 2007 20:18:55 -0400 Received: from netops-testserver-3-out.sgi.com ([192.48.171.28]:37202 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1761801AbXHHASy (ORCPT ); Tue, 7 Aug 2007 20:18:54 -0400 Date: Tue, 7 Aug 2007 17:13:52 -0700 (PDT) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Peter Zijlstra cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, David Miller , Andrew Morton , Daniel Phillips , Pekka Enberg , Matt Mackall , Lee Schermerhorn , Steve Dickson Subject: Re: [PATCH 04/10] mm: slub: add knowledge of reserve pages In-Reply-To: <20070806103658.603735000@chello.nl> Message-ID: References: <20070806102922.907530000@chello.nl> <20070806103658.603735000@chello.nl> 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: 1379 Lines: 31 On Mon, 6 Aug 2007, Peter Zijlstra wrote: > Restrict objects from reserve slabs (ALLOC_NO_WATERMARKS) to allocation > contexts that are entitled to it. Is this patch actually necessary? If you are in an atomic context and bound to a cpu then a per cpu slab is assigned to you and no one else can take object aways from that process since nothing else can run on the cpu. The point of the patch is to avoid other processes draining objects right? So you do not need the modifications in that case. If you are not in an atomic context and are preemptable or can switch allocation context then you can create another context in which reclaim could be run to remove some clean pages and get you more memory. Again no need for the patch. I guess you may be limited in not being able to call into reclaim again because it is already running. Maybe that can be fixed? F.e. zone reclaim does that for the NUMA case. It simply scans for easily reclaimable pages. We could guarantee easily reclaimable pages to exist in much larger numbers than the reserves of min_free_kbytes. So in a tight spot one could reclaim from those. - 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/