[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <84144f020906080352k57f12ff9pbd696da5f332ac1a@mail.gmail.com>
Date: Mon, 8 Jun 2009 13:52:05 +0300
From: Pekka Enberg <penberg@...helsinki.fi>
To: Mel Gorman <mel@....ul.ie>
Cc: Rik van Riel <riel@...hat.com>,
Larry Finger <Larry.Finger@...inger.net>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Kernel Testers List <kernel-testers@...r.kernel.org>,
Johannes Berg <johannes@...solutions.net>,
Andrew Morton <akpm@...ux-foundation.org>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
Christoph Lameter <cl@...ux-foundation.org>
Subject: Re: [Bug #13319] Page allocation failures with b43 and p54usb
On Mon, Jun 8, 2009 at 1:17 PM, Mel Gorman<mel@....ul.ie> 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.
Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists