From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752018AbdIMOwF (ORCPT ); Wed, 13 Sep 2017 10:52:05 -0400 Received: from mail-oi0-f45.google.com ([209.85.218.45]:46630 "EHLO mail-oi0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751686AbdIMOwE (ORCPT ); Wed, 13 Sep 2017 10:52:04 -0400 X-Google-Smtp-Source: AOwi7QDdkQky7IpSB8c/hFxxjUXOHxsJdbZX2FCQJQg7bxbHNZ1jrQuCnzyswwMAoqOOLV+sxNxNE+oc8I67aP0elps= MIME-Version: 1.0 In-Reply-To: References: <20170911082650.dqfirwc63xy7i33q@dhcp22.suse.cz> From: Shakeel Butt Date: Wed, 13 Sep 2017 07:52:02 -0700 Message-ID: Subject: Re: [PATCH] mm: respect the __GFP_NOWARN flag when warning about stalls To: Vlastimil Babka Cc: Mikulas Patocka , Michal Hocko , Tetsuo Handa , Johannes Weiner , Mel Gorman , Dave Hansen , Andrew Morton , Linux MM , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > We would have to consider (instead of jiffies) the time the process was > either running, or waiting on something that's related to memory > allocation/reclaim (page lock etc.). I.e. deduct the time the process > was runable but there was no available cpu. I expect however that such > level of detail wouldn't be feasible here, though? > Johannes' memdelay work (once merged) might be useful here. I think memdalay can differentiate between an allocating process getting delayed due to preemption or due to unsuccessful reclaim/compaction. If the delay is due to unsuccessful reclaim/compaction then we should warn here. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f71.google.com (mail-oi0-f71.google.com [209.85.218.71]) by kanga.kvack.org (Postfix) with ESMTP id 27B9D6B0038 for ; Wed, 13 Sep 2017 10:52:06 -0400 (EDT) Received: by mail-oi0-f71.google.com with SMTP id i6so546917oih.1 for ; Wed, 13 Sep 2017 07:52:06 -0700 (PDT) Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id p25sor6268421oie.207.2017.09.13.07.52.04 for (Google Transport Security); Wed, 13 Sep 2017 07:52:04 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20170911082650.dqfirwc63xy7i33q@dhcp22.suse.cz> From: Shakeel Butt Date: Wed, 13 Sep 2017 07:52:02 -0700 Message-ID: Subject: Re: [PATCH] mm: respect the __GFP_NOWARN flag when warning about stalls Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Vlastimil Babka Cc: Mikulas Patocka , Michal Hocko , Tetsuo Handa , Johannes Weiner , Mel Gorman , Dave Hansen , Andrew Morton , Linux MM , LKML > > We would have to consider (instead of jiffies) the time the process was > either running, or waiting on something that's related to memory > allocation/reclaim (page lock etc.). I.e. deduct the time the process > was runable but there was no available cpu. I expect however that such > level of detail wouldn't be feasible here, though? > Johannes' memdelay work (once merged) might be useful here. I think memdalay can differentiate between an allocating process getting delayed due to preemption or due to unsuccessful reclaim/compaction. If the delay is due to unsuccessful reclaim/compaction then we should warn here. -- 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