From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755092AbZEIWkX (ORCPT ); Sat, 9 May 2009 18:40:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752626AbZEIWkH (ORCPT ); Sat, 9 May 2009 18:40:07 -0400 Received: from smtp-out.google.com ([216.239.45.13]:27228 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752527AbZEIWkG (ORCPT ); Sat, 9 May 2009 18:40:06 -0400 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:user-agent:mime-version:content-type:x-system-of-record; b=p9YZ2luFit3JlAbSx5GpSvqsdtexujs/EKZIIGhuBn3wP8/hk7OVWuFkmYqB2jEGG wMJ8HMnL0WzNZhXOI0DzA== Date: Sat, 9 May 2009 15:39:56 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: "Rafael J. Wysocki" cc: Andrew Morton , fengguang.wu@intel.com, linux-pm@lists.linux-foundation.org, pavel@ucw.cz, Linus Torvalds , jens.axboe@oracle.com, alan-jenkins@tuffmail.co.uk, linux-kernel@vger.kernel.org, kernel-testers@vger.kernel.org, Mel Gorman Subject: Re: [PATCH 1/5] mm: Add __GFP_NO_OOM_KILL flag In-Reply-To: <200905092337.39906.rjw@sisk.pl> Message-ID: References: <200905090155.44635.rjw@sisk.pl> <200905092337.39906.rjw@sisk.pl> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 9 May 2009, Rafael J. Wysocki wrote: > > This has been changed in the latest mmotm with Mel's page alloactor > > patches (and I think yours should be based on mmotm). Specifically, > > page-allocator-break-up-the-allocator-entry-point-into-fast-and-slow-paths.patch. > > > > Before his patchset, zonelists that had ZONE_OOM_LOCKED set for at least > > one of their zones would unconditionally goto restart. Now, if > > order > PAGE_ALLOC_COSTLY_ORDER, it gives up and returns NULL. Otherwise, > > it does goto restart. > > > > So if your allocation has order > PAGE_ALLOC_COSTLY_ORDER, > > It doesn't. All of my allocations are of order 0. > All order 0 allocations are implicitly __GFP_NOFAIL and will loop endlessly unless they can't block. So if you want to simply prohibit the oom killer from being invoked and not change the retry behavior, setting ZONE_OOM_LOCKED for all zones will do that. If your machine hangs, it means nothing can be reclaimed and you can't free memory via oom killing, so there's nothing else the page allocator can do. From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Rientjes Subject: Re: [PATCH 1/5] mm: Add __GFP_NO_OOM_KILL flag Date: Sat, 9 May 2009 15:39:56 -0700 (PDT) Message-ID: References: <200905090155.44635.rjw@sisk.pl> <200905092337.39906.rjw@sisk.pl> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1241908804; bh=P88styYVldS4YEjF0q1AzCda1NA=; h=DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject: In-Reply-To:Message-ID:References:User-Agent:MIME-Version: Content-Type:X-System-Of-Record; b=QWIkqT6SapW9tKE5/G8sa+ozZtkh7gL YTuV/g42KNH9/cLDlRw/zZYhrHaayCWl1LqyehbqrY+NWDSueSb3G4A== In-Reply-To: <200905092337.39906.rjw-KKrjLPT3xs0@public.gmane.org> Sender: kernel-testers-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: TEXT/PLAIN; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "Rafael J. Wysocki" Cc: Andrew Morton , fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, pavel-+ZI9xUNit7I@public.gmane.org, Linus Torvalds , jens.axboe-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, alan-jenkins-cCz0Lq7MMjm9FHfhHBbuYA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kernel-testers-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mel Gorman On Sat, 9 May 2009, Rafael J. Wysocki wrote: > > This has been changed in the latest mmotm with Mel's page alloactor > > patches (and I think yours should be based on mmotm). Specifically, > > page-allocator-break-up-the-allocator-entry-point-into-fast-and-slow-paths.patch. > > > > Before his patchset, zonelists that had ZONE_OOM_LOCKED set for at least > > one of their zones would unconditionally goto restart. Now, if > > order > PAGE_ALLOC_COSTLY_ORDER, it gives up and returns NULL. Otherwise, > > it does goto restart. > > > > So if your allocation has order > PAGE_ALLOC_COSTLY_ORDER, > > It doesn't. All of my allocations are of order 0. > All order 0 allocations are implicitly __GFP_NOFAIL and will loop endlessly unless they can't block. So if you want to simply prohibit the oom killer from being invoked and not change the retry behavior, setting ZONE_OOM_LOCKED for all zones will do that. If your machine hangs, it means nothing can be reclaimed and you can't free memory via oom killing, so there's nothing else the page allocator can do.