From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752073AbdIMOfT (ORCPT ); Wed, 13 Sep 2017 10:35:19 -0400 Received: from mx2.suse.de ([195.135.220.15]:48704 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751912AbdIMOfN (ORCPT ); Wed, 13 Sep 2017 10:35:13 -0400 Date: Wed, 13 Sep 2017 16:35:09 +0200 From: Michal Hocko To: Tetsuo Handa Cc: vbabka@suse.cz, mpatocka@redhat.com, hannes@cmpxchg.org, mgorman@suse.de, dave.hansen@intel.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: respect the __GFP_NOWARN flag when warning about stalls Message-ID: <20170913143509.6wtp3pd5yhqe53ck@dhcp22.suse.cz> References: <20170911082650.dqfirwc63xy7i33q@dhcp22.suse.cz> <20170913115442.4tpbiwu77y7lrz6g@dhcp22.suse.cz> <201709132254.DEE34807.LQOtMFOFJSOVHF@I-love.SAKURA.ne.jp> <201709132314.BID39077.HMFOJSLFtVOFOQ@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201709132314.BID39077.HMFOJSLFtVOFOQ@I-love.SAKURA.ne.jp> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 13-09-17 23:14:43, Tetsuo Handa wrote: > Vlastimil Babka wrote: > > On 09/13/2017 03:54 PM, Tetsuo Handa wrote: > > > Michal Hocko wrote: > > >> Let's see what others think about this. > > > > > > Whether __GFP_NOWARN should warn about stalls is not a topic to discuss. > > > > It is the topic of this thread, which tries to address a concrete > > problem somebody has experienced. In that context, the rest of your > > concerns seem to me not related to this problem, IMHO. > > I suggested replacing warn_alloc() with safe/useful one rather than tweaking > warn_alloc() about __GFP_NOWARN. What you seem to ignore is that whatever method you use for reporting stalling allocations you would still have to consider whether to dump a stall information for __GFP_NOWARN ones. And as the current report shows that might be a bad idea. So please stick to the topic and do not move it towards _what_ is the proper way of stall detection. -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) by kanga.kvack.org (Postfix) with ESMTP id 8E5A86B0038 for ; Wed, 13 Sep 2017 10:35:13 -0400 (EDT) Received: by mail-wm0-f70.google.com with SMTP id m127so968451wmm.3 for ; Wed, 13 Sep 2017 07:35:13 -0700 (PDT) Received: from mx1.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id 2si1230861wmc.93.2017.09.13.07.35.12 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 13 Sep 2017 07:35:12 -0700 (PDT) Date: Wed, 13 Sep 2017 16:35:09 +0200 From: Michal Hocko Subject: Re: [PATCH] mm: respect the __GFP_NOWARN flag when warning about stalls Message-ID: <20170913143509.6wtp3pd5yhqe53ck@dhcp22.suse.cz> References: <20170911082650.dqfirwc63xy7i33q@dhcp22.suse.cz> <20170913115442.4tpbiwu77y7lrz6g@dhcp22.suse.cz> <201709132254.DEE34807.LQOtMFOFJSOVHF@I-love.SAKURA.ne.jp> <201709132314.BID39077.HMFOJSLFtVOFOQ@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201709132314.BID39077.HMFOJSLFtVOFOQ@I-love.SAKURA.ne.jp> Sender: owner-linux-mm@kvack.org List-ID: To: Tetsuo Handa Cc: vbabka@suse.cz, mpatocka@redhat.com, hannes@cmpxchg.org, mgorman@suse.de, dave.hansen@intel.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org On Wed 13-09-17 23:14:43, Tetsuo Handa wrote: > Vlastimil Babka wrote: > > On 09/13/2017 03:54 PM, Tetsuo Handa wrote: > > > Michal Hocko wrote: > > >> Let's see what others think about this. > > > > > > Whether __GFP_NOWARN should warn about stalls is not a topic to discuss. > > > > It is the topic of this thread, which tries to address a concrete > > problem somebody has experienced. In that context, the rest of your > > concerns seem to me not related to this problem, IMHO. > > I suggested replacing warn_alloc() with safe/useful one rather than tweaking > warn_alloc() about __GFP_NOWARN. What you seem to ignore is that whatever method you use for reporting stalling allocations you would still have to consider whether to dump a stall information for __GFP_NOWARN ones. And as the current report shows that might be a bad idea. So please stick to the topic and do not move it towards _what_ is the proper way of stall detection. -- Michal Hocko SUSE Labs -- 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