Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754837AbZFHLDS (ORCPT ); Mon, 8 Jun 2009 07:03:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754392AbZFHLDF (ORCPT ); Mon, 8 Jun 2009 07:03:05 -0400 Received: from gir.skynet.ie ([193.1.99.77]:51293 "EHLO gir.skynet.ie" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753696AbZFHLDE (ORCPT ); Mon, 8 Jun 2009 07:03:04 -0400 Date: Mon, 8 Jun 2009 12:03:03 +0100 From: Mel Gorman To: Pekka Enberg Cc: Rik van Riel , Larry Finger , "Rafael J. Wysocki" , Linux Kernel Mailing List , Kernel Testers List , Johannes Berg , Andrew Morton , KOSAKI Motohiro , KAMEZAWA Hiroyuki , Christoph Lameter Subject: Re: [Bug #13319] Page allocation failures with b43 and p54usb Message-ID: <20090608110303.GD15377@csn.ul.ie> References: <4A2BBC30.2030300@lwfinger.net> <84144f020906070640rf5ab14nbf66d3ca7c97675f@mail.gmail.com> <4A2BCC6F.8090004@redhat.com> <84144f020906070732l31786156r5d9753a0cabfde79@mail.gmail.com> <20090608101739.GA15377@csn.ul.ie> <84144f020906080352k57f12ff9pbd696da5f332ac1a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <84144f020906080352k57f12ff9pbd696da5f332ac1a@mail.gmail.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1503 Lines: 30 On Mon, Jun 08, 2009 at 01:52:05PM +0300, Pekka Enberg wrote: > On Mon, Jun 8, 2009 at 1:17 PM, Mel Gorman wrote: > > Pekka, assuming the request size is 800 bytes, and SLUB is using order-1 > > pages for allocations of that size, what happened order-1 allocations > > falling back to order-0 allocations as necessary. That logic exists, > > right? If so, could it be broken? > > That logic is in allocate_slab() and if the higher order allocation > fails, we fall-back to struct kmem_cache ->min order. That in turn is > set up in calculate_sizes() to get_order(size) so it seems pretty > unlikely to me the allocation is 800 bytes. Of course, I could be > missing something here and there's a bug in oo_make() or oo_order(). > Hmm. Is there any chance you could hatchet together a patch slab-allocation-failure that reports on slab allocation failures similar to what the page allocator does? Minimally, it should tell us what the size of the allocation was but any other information such as the same of the slab, the size of pages it normally uses are, etc. would also be useful. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- 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/