From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751929Ab1GTTJl (ORCPT ); Wed, 20 Jul 2011 15:09:41 -0400 Received: from cantor2.suse.de ([195.135.220.15]:45221 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751593Ab1GTTJk (ORCPT ); Wed, 20 Jul 2011 15:09:40 -0400 Date: Wed, 20 Jul 2011 20:09:33 +0100 From: Mel Gorman To: Pekka Enberg Cc: Christoph Lameter , Eric Dumazet , Konstantin Khlebnikov , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Matt Mackall Subject: Re: [PATCH] mm-slab: allocate kmem_cache with __GFP_REPEAT Message-ID: <20110720190933.GN5349@suse.de> References: <1311174562.2338.42.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> <1311177362.2338.57.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> <1311179465.2338.62.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> <1311181463.2338.72.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 20, 2011 at 08:41:12PM +0300, Pekka Enberg wrote: > On Wed, 20 Jul 2011, Pekka Enberg wrote: > >>On Wed, 20 Jul 2011, Eric Dumazet wrote: > >>>>[PATCH v2] slab: shrinks sizeof(struct kmem_cache) > >> > >>On Wed, 20 Jul 2011, Christoph Lameter wrote: > >>>This will solve the issue for small nr_cpu_ids but those with 4k cpus will > >>>still have the issue. > >>> > >>>Acked-by: Christoph Lameter > >> > >>Applied, thanks! Do we still want the __GFP_REPEAT patch from Konstantin > >>though? > > On Wed, 20 Jul 2011, Christoph Lameter wrote: > >Those with 4k cpus will be thankful I guess. > > OTOH, I'm slightly worried that it might mask a real problem with > GFP_KERNEL not being aggressive enough. Mel? > The reproduction case was while memory was under heavy pressure (swapout was active) and even then only 1 in a 1000 containers were failing to create due to an order-4 allocation failure. I'm not convinced we need to increase how aggressive the allocator is for PAGE_ALLOC_COSTLY_ORDER in general based on this. -- Mel Gorman SUSE Labs