From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail190.messagelabs.com (mail190.messagelabs.com [216.82.249.51]) by kanga.kvack.org (Postfix) with SMTP id 89F4E6B0047 for ; Tue, 21 Apr 2009 05:03:26 -0400 (EDT) Received: from m5.gw.fujitsu.co.jp ([10.0.50.75]) by fgwmail7.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id n3L93Rlh028972 for (envelope-from kosaki.motohiro@jp.fujitsu.com); Tue, 21 Apr 2009 18:03:27 +0900 Received: from smail (m5 [127.0.0.1]) by outgoing.m5.gw.fujitsu.co.jp (Postfix) with ESMTP id EC61D45DE57 for ; Tue, 21 Apr 2009 18:03:26 +0900 (JST) Received: from s5.gw.fujitsu.co.jp (s5.gw.fujitsu.co.jp [10.0.50.95]) by m5.gw.fujitsu.co.jp (Postfix) with ESMTP id C30A445DE51 for ; Tue, 21 Apr 2009 18:03:26 +0900 (JST) Received: from s5.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s5.gw.fujitsu.co.jp (Postfix) with ESMTP id A2706E08008 for ; Tue, 21 Apr 2009 18:03:26 +0900 (JST) Received: from m105.s.css.fujitsu.com (m105.s.css.fujitsu.com [10.249.87.105]) by s5.gw.fujitsu.co.jp (Postfix) with ESMTP id 562491DB805E for ; Tue, 21 Apr 2009 18:03:26 +0900 (JST) From: KOSAKI Motohiro Subject: Re: [PATCH 10/25] Calculate the alloc_flags for allocation only once In-Reply-To: <1240266011-11140-11-git-send-email-mel@csn.ul.ie> References: <1240266011-11140-1-git-send-email-mel@csn.ul.ie> <1240266011-11140-11-git-send-email-mel@csn.ul.ie> Message-Id: <20090421165022.F13F.A69D9226@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Tue, 21 Apr 2009 18:03:25 +0900 (JST) Sender: owner-linux-mm@kvack.org To: Mel Gorman Cc: kosaki.motohiro@jp.fujitsu.com, Linux Memory Management List , Christoph Lameter , Nick Piggin , Linux Kernel Mailing List , Lin Ming , Zhang Yanmin , Peter Zijlstra , Pekka Enberg , Andrew Morton List-ID: > Factor out the mapping between GFP and alloc_flags only once. Once factored > out, it only needs to be calculated once but some care must be taken. > > [neilb@suse.de says] > As the test: > > - if (((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE))) > - && !in_interrupt()) { > - if (!(gfp_mask & __GFP_NOMEMALLOC)) { > > has been replaced with a slightly weaker one: > > + if (alloc_flags & ALLOC_NO_WATERMARKS) { > > we need to ensure we don't recurse when PF_MEMALLOC is set. It seems good idea. > +static inline int > +gfp_to_alloc_flags(gfp_t gfp_mask) > +{ > + struct task_struct *p = current; > + int alloc_flags = ALLOC_WMARK_MIN | ALLOC_CPUSET; > + const gfp_t wait = gfp_mask & __GFP_WAIT; > + > + /* > + * The caller may dip into page reserves a bit more if the caller > + * cannot run direct reclaim, or if the caller has realtime scheduling > + * policy or is asking for __GFP_HIGH memory. GFP_ATOMIC requests will > + * set both ALLOC_HARDER (!wait) and ALLOC_HIGH (__GFP_HIGH). > + */ > + if (gfp_mask & __GFP_HIGH) > + alloc_flags |= ALLOC_HIGH; > + > + if (!wait) { > + alloc_flags |= ALLOC_HARDER; > + /* > + * Ignore cpuset if GFP_ATOMIC (!wait) rather than fail alloc. > + * See also cpuset_zone_allowed() comment in kernel/cpuset.c. > + */ > + alloc_flags &= ~ALLOC_CPUSET; > + } else if (unlikely(rt_task(p)) && !in_interrupt()) wait==1 and in_interrupt==1 is never occur. I think in_interrupt check can be removed. > /* Atomic allocations - we can't balance anything */ > if (!wait) > goto nopage; > > + /* Avoid recursion of direct reclaim */ > + if (p->flags & PF_MEMALLOC) > + goto nopage; > + Again. old code doesn't only check PF_MEMALLOC, but also check TIF_MEMDIE. > /* Try direct reclaim and then allocating */ > page = __alloc_pages_direct_reclaim(gfp_mask, order, > zonelist, high_zoneidx, > -- > 1.5.6.5 > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org