Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753492Ab2JPNJg (ORCPT ); Tue, 16 Oct 2012 09:09:36 -0400 Received: from mail-pb0-f46.google.com ([209.85.160.46]:49843 "EHLO mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752255Ab2JPNJe (ORCPT ); Tue, 16 Oct 2012 09:09:34 -0400 Date: Tue, 16 Oct 2012 22:09:27 +0900 From: Minchan Kim To: Ming Lei Cc: linux-kernel@vger.kernel.org, Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-pm@vger.kernel.org, Alan Stern , Oliver Neukum , Jiri Kosina , Andrew Morton , Mel Gorman , KAMEZAWA Hiroyuki , Michal Hocko , Ingo Molnar , Peter Zijlstra , "Rafael J. Wysocki" , linux-mm Subject: Re: [RFC PATCH 1/3] mm: teach mm by current context info to not do I/O during memory allocation Message-ID: <20121016130927.GA5603@barrios> References: <1350278059-14904-1-git-send-email-ming.lei@canonical.com> <1350278059-14904-2-git-send-email-ming.lei@canonical.com> <20121015154724.GA2840@barrios> <20121016054946.GA3934@barrios> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2817 Lines: 92 On Tue, Oct 16, 2012 at 03:08:41PM +0800, Ming Lei wrote: > On Tue, Oct 16, 2012 at 1:49 PM, Minchan Kim wrote: > > > > Fair enough but it wouldn't be a good idea that add new unlikely branch > > in allocator's fast path. Please move the check into slow path which could > > be in __alloc_pages_slowpath. > > Thanks for your comment. > > I have considered to add the branch into gfp_to_alloc_flags() before, > but didn't do it because I see that get_page_from_freelist() may use > the GFP_IO or GFP_FS flag at least in zone_reclaim() path. Good point. You can check it in __zone_reclaim and change gfp_mask of scan_control because it's never hot path. > > So could you make sure it is safe to move the branch into > __alloc_pages_slowpath()? If so, I will add the check into > gfp_to_alloc_flags(). How about this? diff --git a/mm/page_alloc.c b/mm/page_alloc.c index d976957..b3607fa 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2614,10 +2614,16 @@ retry_cpuset: page = get_page_from_freelist(gfp_mask|__GFP_HARDWALL, nodemask, order, zonelist, high_zoneidx, alloc_flags, preferred_zone, migratetype); - if (unlikely(!page)) + if (unlikely(!page)) { + /* + * Resume path can deadlock because block device + * isn't active yet. + */ + if (unlikely(tsk_memalloc_no_io(current))) + gfp_mask &= ~GFP_IOFS; page = __alloc_pages_slowpath(gfp_mask, order, zonelist, high_zoneidx, nodemask, preferred_zone, migratetype); + } trace_mm_page_alloc(page, order, gfp_mask, migratetype); diff --git a/mm/vmscan.c b/mm/vmscan.c index b5e45f4..6c2ccdd 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -3290,6 +3290,16 @@ static int __zone_reclaim(struct zone *zone, gfp_t gfp_mask, unsigned int order) }; unsigned long nr_slab_pages0, nr_slab_pages1; + if (unlikely(tsk_memalloc_no_io(current))) { + sc.gfp_mask &= ~GFP_IOFS; + shrink.gfp_mask = sc.gfp_mask; + /* + * We allow to reclaim only clean pages. + * It can affect RECLAIM_SWAP and RECLAIM_WRITE mode + * but this is really rare event and allocator can * fallback to other zones. + */ + sc.may_writepage = 0; + sc.may_swap = 0; + } + cond_resched(); /* * We need to be able to allocate from the reserves for RECLAIM_SWAP > > > Thanks, > -- > Ming Lei > > -- > 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 -- Kind Regards, Minchan Kim -- 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/