From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [RFC][PATCH 1/6] mm: slab allocation fairness Date: Thu, 30 Nov 2006 21:15:15 +0100 Message-ID: <1164917715.6588.177.camel@twins> References: <20061130101451.495412000@chello.nl> > <20061130101921.113055000@chello.nl> > <1164913365.6588.156.camel@twins> <1164915612.6588.171.camel@twins> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, linux-mm@kvack.org, David Miller Return-path: Received: from amsfep17-int.chello.nl ([213.46.243.15]:20668 "EHLO amsfep16-int.chello.nl") by vger.kernel.org with ESMTP id S1031346AbWK3UV3 (ORCPT ); Thu, 30 Nov 2006 15:21:29 -0500 To: Christoph Lameter In-Reply-To: Sender: netdev-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Thu, 2006-11-30 at 12:11 -0800, Christoph Lameter wrote: > On Thu, 30 Nov 2006, Peter Zijlstra wrote: > > > Sure, but there is nothing wrong with using a slab page with a lower > > allocation rank when there is memory aplenty. > > What does "a slab page with a lower allocation rank" mean? Slab pages have > no allocation ranks that I am aware of. I just added allocation rank and didn't you suggest tracking it for all slab pages instead of per slab? The rank is an expression of how hard it was to get that page, with 0 being the hardest allocation (ALLOC_NO_WATERMARK) and 16 the easiest (ALLOC_WMARK_HIGH). I store the rank of the last allocated page and retest the rank when a gfp flag indicates a higher rank, that is when the current slab allocation would have failed to grow the slab under the conditions of the previous allocation.