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, 9 Jun 2009 10:50:28 +0300 Message-ID: <84144f020906090050y351e3e9cmb69a089e1a996cd4@mail.gmail.com> 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> <20090608110303.GD15377@csn.ul.ie> <20090608141212.GE15070@csn.ul.ie> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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=DWNnL6Pk/Gc/03H21Z5qfNLEMBBXYDWqrX4zFlicM9g=; b=JfzJ4CfsuSGNg7HJ0o/kf8h6jYBiKqHGCh47sm5qQB0tFC3zG80G9YS68cFqNj57/7 64J4AN5oLGDYXqYgS2eIGOLTo58AmJfo1w9b2n6/qfOi+vv67A0j+w2rr9AyS+tLAzuD e9TghCBjtpyx/qZGFLuEifkWzCZEmSm8BTKWU= In-Reply-To: <20090608141212.GE15070-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org> Sender: kernel-testers-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Mel Gorman 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 On Mon, Jun 8, 2009 at 5:12 PM, Mel Gorman wrote: > In addition, include how many objects there are per-slab and include what > the order is being passed to the page allocator when allocating new slabs. > Would that be enough to determine if fallback-to-smaller orders occured? Well, if the slab_out_of_memory() is called, we already know the higher order allocation failed _and_ the fallback allocation failed. So yes, it would be enough. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758191AbZFIHug (ORCPT ); Tue, 9 Jun 2009 03:50:36 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754834AbZFIHu3 (ORCPT ); Tue, 9 Jun 2009 03:50:29 -0400 Received: from mail-fx0-f213.google.com ([209.85.220.213]:63723 "EHLO mail-fx0-f213.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754784AbZFIHu2 (ORCPT ); Tue, 9 Jun 2009 03:50:28 -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=AFMdck5MS4PmaxatZg/tnAwGASU+r0g1xgt+lz1h0Di3k6sJ2DvZukcDQMWo4pd5OM mNTBx62e9jYuwwy0vZdVETXWOLuAtxnoX6VkHucQ4L2FBtZJZxDIPCLX2gpoZWH59uo1 Q6x2FIZfMD4ejckgtgUYcHIAizDwne0klORTU= MIME-Version: 1.0 In-Reply-To: <20090608141212.GE15070@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> <20090608110303.GD15377@csn.ul.ie> <20090608141212.GE15070@csn.ul.ie> Date: Tue, 9 Jun 2009 10:50:28 +0300 X-Google-Sender-Auth: 54c3e314add1e3cc Message-ID: <84144f020906090050y351e3e9cmb69a089e1a996cd4@mail.gmail.com> Subject: Re: [Bug #13319] Page allocation failures with b43 and p54usb From: Pekka Enberg To: Mel Gorman 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 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 8, 2009 at 5:12 PM, Mel Gorman wrote: > In addition, include how many objects there are per-slab and include what > the order is being passed to the page allocator when allocating new slabs. > Would that be enough to determine if fallback-to-smaller orders occured? Well, if the slab_out_of_memory() is called, we already know the higher order allocation failed _and_ the fallback allocation failed. So yes, it would be enough.