From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755837AbZF3Gza (ORCPT ); Tue, 30 Jun 2009 02:55:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753358AbZF3GzW (ORCPT ); Tue, 30 Jun 2009 02:55:22 -0400 Received: from mail-bw0-f213.google.com ([209.85.218.213]:40651 "EHLO mail-bw0-f213.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753167AbZF3GzV convert rfc822-to-8bit (ORCPT ); Tue, 30 Jun 2009 02:55:21 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=IRsdd39df5tks36d47nEkOVcfPxejGEyb9Dd+u24RImQWnuMZ0cQnGl0qUMe8aOpGv 9DEDh6Nm7SMz9M8OS4O1mcIOn6DKlRqhjipbDmQXQD5hepoBYLUO+lpghdWjqY2xUBiz ZOZatvuCj/aV+DZLfbcMrMX5rGI3CVP4WSKdQ= MIME-Version: 1.0 In-Reply-To: References: <5Hhc7UkUKEO.A.fNH.4kASKB@chimera> <4A48F114.1010702@lwfinger.net> Date: Tue, 30 Jun 2009 09:55:22 +0300 X-Google-Sender-Auth: 262845fc1ad9c3bf Message-ID: <84144f020906292355o7cf63f7ch47bd19961cf92da3@mail.gmail.com> Subject: Re: [Bug #13319] Page allocation failures with b43 and p54usb From: Pekka Enberg To: David Rientjes Cc: Larry Finger , "Rafael J. Wysocki" , Linux Kernel Mailing List , Kernel Testers List , Johannes Berg , Christoph Lameter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi David, On Tue, Jun 30, 2009 at 2:47 AM, David Rientjes wrote: > On Mon, 29 Jun 2009, Larry Finger wrote: > >> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=13319 >> > Subject             : Page allocation failures with b43 and p54usb >> > Submitter   : Larry Finger >> > Date                : 2009-04-29 21:01 (61 days old) >> > References  : http://marc.info/?l=linux-kernel&m=124103897101088&w=4 >> >               http://lkml.org/lkml/2009/6/7/136 >> > Handled-By  : Johannes Berg >> >> The cause of these failures has been determined. The wireless >> subsystem frequently requests buffers of size 4096, but when SLUB >> debugging is enabled and the debug info is added, the request becomes >> of order 1 and memory becomes fragmented. >> >> A controversial "fix" in which SLUB debugging was disabled for >> allocations where adding such debugging info would increase the order >> was discussed and tried. With a quick look at the commit list for >> Linus's tree, I don't see that such a patch is available, but I will >> be corrected if I missed it. >> > > I'd disagree with disabling slub debugging by default for caches where > oo_order(s->min) increases as the result of using it.  This particular > page allocation failure is happening for, presumably, kmalloc-4096, and > the system has 4K pages.  Disabling debugging for that cache (and any of > its aliases) implicitly will lead to errors going undiagnosed as a result. Well, I obviously don't agree here because kmalloc-4096 debugging causes problems in the real world. Furthermore, SLUB never supported debugging for objects that big historically because of page allocator passthrough. And with Mel Gorman's page allocator optimizations, we might be going back to that. So we should fix SLUB debugging as outlined by Mel Gorman and Christoph Lameter. I simply haven't had the time to do it. Patches are welcome! Pekka From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pekka Enberg Subject: Re: [Bug #13319] Page allocation failures with b43 and p54usb Date: Tue, 30 Jun 2009 09:55:22 +0300 Message-ID: <84144f020906292355o7cf63f7ch47bd19961cf92da3@mail.gmail.com> References: <5Hhc7UkUKEO.A.fNH.4kASKB@chimera> <4A48F114.1010702@lwfinger.net> Mime-Version: 1.0 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=F2raUant5mjqP5G9nuBTu14tPAiaHo379r9of+tQtW8=; b=OekMf6eulLHXCmIsThIzw9KeUhIu/2FVC/htqd6rBr6QRGWTXkC8Gv6qVSFuROdRRs Ei5y9ZRAqYjJWzkSl3AlOIFAvTmaGiiYs5s/xd6L2JY3S7jgAB5eROzn4veH4gbawk9Z TTSLG3QO6vrq6EXqCB6QtJlKY3gmFy1CvCaB0= In-Reply-To: Sender: kernel-testers-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="iso-8859-1" To: David Rientjes Cc: Larry Finger , "Rafael J. Wysocki" , Linux Kernel Mailing List , Kernel Testers List , Johannes Berg , Christoph Lameter Hi David, On Tue, Jun 30, 2009 at 2:47 AM, David Rientjes wr= ote: > On Mon, 29 Jun 2009, Larry Finger wrote: > >> > Bug-Entry =A0 : http://bugzilla.kernel.org/show_bug.cgi?id=3D13319 >> > Subject =A0 =A0 =A0 =A0 =A0 =A0 : Page allocation failures with b4= 3 and p54usb >> > Submitter =A0 : Larry Finger >> > Date =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: 2009-04-29 21:01 (61 days ol= d) >> > References =A0: http://marc.info/?l=3Dlinux-kernel&m=3D12410389710= 1088&w=3D4 >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://lkml.org/lkml/2009/6/7/136 >> > Handled-By =A0: Johannes Berg >> >> The cause of these failures has been determined. The wireless >> subsystem frequently requests buffers of size 4096, but when SLUB >> debugging is enabled and the debug info is added, the request become= s >> of order 1 and memory becomes fragmented. >> >> A controversial "fix" in which SLUB debugging was disabled for >> allocations where adding such debugging info would increase the orde= r >> was discussed and tried. With a quick look at the commit list for >> Linus's tree, I don't see that such a patch is available, but I will >> be corrected if I missed it. >> > > I'd disagree with disabling slub debugging by default for caches wher= e > oo_order(s->min) increases as the result of using it. =A0This particu= lar > page allocation failure is happening for, presumably, kmalloc-4096, a= nd > the system has 4K pages. =A0Disabling debugging for that cache (and a= ny of > its aliases) implicitly will lead to errors going undiagnosed as a re= sult. Well, I obviously don't agree here because kmalloc-4096 debugging causes problems in the real world. Furthermore, SLUB never supported debugging for objects that big historically because of page allocator passthrough. And with Mel Gorman's page allocator optimizations, we might be going back to that. So we should fix SLUB debugging as outlined by Mel Gorman and Christoph Lameter. I simply haven't had the time to do it. Patches are welcome! Pekka