From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 24 May 2007 09:36:16 -0700 (PDT) From: Christoph Lameter Subject: Re: [patch 1/3] slob: rework freelist handling In-Reply-To: <20070524061153.GP11115@waste.org> Message-ID: References: <20070523071200.GB9449@wotan.suse.de> <20070523183224.GD11115@waste.org> <20070523195824.GF11115@waste.org> <20070523210612.GI11115@waste.org> <20070523224206.GN11115@waste.org> <20070524061153.GP11115@waste.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Matt Mackall Cc: Nick Piggin , Andrew Morton , Linux Memory Management List List-ID: On Thu, 24 May 2007, Matt Mackall wrote: > So, here's three possible approaches to this issue: > > A) Continue to ignore it. Doing something about it would add > complexity and it's not clear that it's a win. > > B) Set NR_SLAB_RECLAIMABLE to 1. If the VM starts checking that to > decide whether it should call shrinkers, things will continue to work. > Increment and decrement NR_SLAB_UNRECLAIMABLE when we grow/shrink the > SLOB pool. This is probably 3 lines of code total. > > C) Fake NR_SLAB_RECLAIMABLE/NR_SLAB_UNRECLAIMABLE based on actual > allocs and slab flags such that they sum to the total pages in the > SLOB pool. This would need a third global counter in bytes of how many > allocs we had in the "reclaimable" slabs. Probably 10-20 lines of > code of marginal utility. > > So, nothing insurmountable here. Just not convinced we should bother. > But the cost of B is so low, perhaps I might as well. D) Do the right thing and implement the counters. At the time of calling alloc_pages() you know that you have to increment either counter but you do not know which. For that purpose you add another byte counter (reclaim_counter) that contains the number of reclaimable bytes allocated. Sum them up during slob_alloc if flags & SLAB_RECLAIM_ACCOUNT is set. Then after a page allocator alloc you check the following: If (NR_SLAB_RECLAIMABLE << PAGE_SHIFT) >= reclaim_counter then increment NR_SLAB_UNRECLAIMABLE otherwise NR_SLAB_RECLAIMABLE. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org