From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S935933AbcIWIuS (ORCPT <rfc822;w@1wt.eu>);
        Fri, 23 Sep 2016 04:50:18 -0400
Received: from out0-139.mail.aliyun.com ([140.205.0.139]:44845 "EHLO
        out0-139.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752772AbcIWIuN (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 23 Sep 2016 04:50:13 -0400
X-Greylist: delayed 316 seconds by postgrey-1.27 at vger.kernel.org; Fri, 23 Sep 2016 04:50:12 EDT
X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R111e4;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03285;MF=hillf.zj@alibaba-inc.com;NM=1;PH=DS;RN=7;SR=0;TI=SMTPD_---.7-cu25e_1474620266;
Reply-To: "Hillf Danton" <hillf.zj@alibaba-inc.com>
From: "Hillf Danton" <hillf.zj@alibaba-inc.com>
To: "'Michal Hocko'" <mhocko@kernel.org>
Cc: <linux-mm@kvack.org>, "'Andrew Morton'" <akpm@linux-foundation.org>,
        "'Johannes Weiner'" <hannes@cmpxchg.org>,
        "'Mel Gorman'" <mgorman@suse.de>,
        "'Tetsuo Handa'" <penguin-kernel@I-love.SAKURA.ne.jp>,
        "'LKML'" <linux-kernel@vger.kernel.org>
References: <20160923081555.14645-1-mhocko@kernel.org> <007901d21574$9ef82d60$dce88820$@alibaba-inc.com> <20160923083224.GF4478@dhcp22.suse.cz>
In-Reply-To: <20160923083224.GF4478@dhcp22.suse.cz>
Subject: Re: [PATCH] mm: warn about allocations which stall for too long
Date: Fri, 23 Sep 2016 16:44:26 +0800
Message-ID: <007a01d21576$b12ac4a0$13804de0$@alibaba-inc.com>
MIME-Version: 1.0
Content-Type: text/plain;
        charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGHGq0LKm8bucSYf4ydRqfGHYZ3FgIRxh44AYG56VqhABm0kA==
Content-Language: zh-cn
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Friday, September 23, 2016 4:32 PM, Michal Hocko wrote
> On Fri 23-09-16 16:29:36, Hillf Danton wrote:
> [...]
> > > @@ -3659,6 +3661,15 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
> > >  	else
> > >  		no_progress_loops++;
> > >
> > > +	/* Make sure we know about allocations which stall for too long */
> > > +	if (!(gfp_mask & __GFP_NOWARN) && time_after(jiffies, alloc_start + stall_timeout)) {
> > > +		pr_warn("%s: page alloction stalls for %ums: order:%u mode:%#x(%pGg)\n",
> > > +				current->comm, jiffies_to_msecs(jiffies-alloc_start),
> >
> > Better if pid is also printed.
> 
> I've tried to be consistent with warn_alloc_failed and that doesn't
> print pid either. Maybe both of them should. Dunno
> 
With pid imho we can distinguish two tasks with same name in a simpler way. 

> > > +				order, gfp_mask, &gfp_mask);
> > > +		stall_timeout += 10 * HZ;
> >
> > Alternatively	 alloc_start = jiffies;
> 
> Then we would lose the cumulative time in the output which is imho
> helpful because you cannot tell whether the new warning is a new request
> or the old one still looping.
> 
Fair.

thanks
Hillf