Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753013AbZJBEmX (ORCPT ); Fri, 2 Oct 2009 00:42:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752789AbZJBEmX (ORCPT ); Fri, 2 Oct 2009 00:42:23 -0400 Received: from cantor.suse.de ([195.135.220.2]:51475 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751557AbZJBEmW (ORCPT ); Fri, 2 Oct 2009 00:42:22 -0400 From: Neil Brown To: David Rientjes Date: Fri, 2 Oct 2009 14:43:34 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19141.34038.274185.392663@notabene.brown> Cc: Suresh Jayaraman , Linus Torvalds , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, Miklos Szeredi , Wouter Verhelst , Peter Zijlstra , trond.myklebust@fys.uio.no Subject: Re: [PATCH 04/31] mm: tag reseve pages In-Reply-To: message from David Rientjes on Thursday October 1 References: <1254405917-15796-1-git-send-email-sjayaraman@suse.de> X-Mailer: VM 7.19 under Emacs 21.4.1 X-face: [Gw_3E*Gng}4rRrKRYotwlE?.2|**#s9D X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1761 Lines: 47 On Thursday October 1, rientjes@google.com wrote: > On Thu, 1 Oct 2009, Suresh Jayaraman wrote: > > > Index: mmotm/mm/page_alloc.c > > =================================================================== > > --- mmotm.orig/mm/page_alloc.c > > +++ mmotm/mm/page_alloc.c > > @@ -1501,8 +1501,10 @@ zonelist_scan: > > try_this_zone: > > page = buffered_rmqueue(preferred_zone, zone, order, > > gfp_mask, migratetype); > > - if (page) > > + if (page) { > > + page->reserve = !!(alloc_flags & ALLOC_NO_WATERMARKS); > > break; > > + } > > this_zone_full: > > if (NUMA_BUILD) > > zlc_mark_zone_full(zonelist, z); > > page->reserve won't necessary indicate that access to reserves was > _necessary_ for the allocation to succeed, though. This will mark any > page being allocated under PF_MEMALLOC as reserve when all zones may be > well above their min watermarks. Normally if zones are above their watermarks, page->reserve will not be set. This is because __alloc_page_nodemask (which seems to be the main non-inline entrypoint) first calls get_page_from_freelist with alloc_flags set to ALLOC_WMARK_LOW|ALLOC_CPUSET. Only if this fails does __alloc_page_nodemask call __alloc_pages_slowpath which potentially sets ALLOC_NO_WATERMARKS in alloc_flags. So page->reserved being set actually tells us: PF_MEMALLOC or GFP_MEMALLOC were used, and a WMARK_LOW allocation attempt failed very recently which is close enough to "the emergency reserves were used" I think. Thanks, NeilBrown -- 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/