From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 794CAC433E0 for ; Mon, 8 Mar 2021 15:58:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 12E5665226 for ; Mon, 8 Mar 2021 15:58:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 12E5665226 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 97BF88D0047; Mon, 8 Mar 2021 10:58:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 92B6D8D001D; Mon, 8 Mar 2021 10:58:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A4808D0047; Mon, 8 Mar 2021 10:58:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0136.hostedemail.com [216.40.44.136]) by kanga.kvack.org (Postfix) with ESMTP id 5BCBF8D001D for ; Mon, 8 Mar 2021 10:58:17 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 1CE478249980 for ; Mon, 8 Mar 2021 15:58:17 +0000 (UTC) X-FDA: 77897163834.26.24E4720 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by imf17.hostedemail.com (Postfix) with ESMTP id F36B04080F45 for ; Mon, 8 Mar 2021 15:58:14 +0000 (UTC) Received: by mail-pl1-f173.google.com with SMTP id d23so1857580plq.2 for ; Mon, 08 Mar 2021 07:58:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=tV38FDWXIwSDUgFeSjN3RtzjqUjYpkfwAo3PpwIhaxQ=; b=ErBYBePCPB8Z2yrnGCAAmEr6Cx2IqktbakyWcUtYUMjI6dUa9KhCVu0wnQUdWE6ZZO 7Q3UnwF/9+sIrG0HMnoiv6PEJNQ/+ipbUzGnjGurIFGinBAtR0wiNA9tiyr7yTrxyXXa rHqcNDg+YIuolXpmnVo4q8bIU1AP8r/As32IgdCvy3bsBN4V57mMbA3xVTMFXyG/4+Va D9aCWYzKuqY9meLE1/CItfgSqsk6vPUu19bg/CG2Y/BAT0nCcYul3xa3lULVeqYB9ahf WgeOvenaXWclypW/0ygdxWVGKtMbR4067LG3lmjCPB273JOVSW+BTYU1wxdbnfmBh6Yg XoSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=tV38FDWXIwSDUgFeSjN3RtzjqUjYpkfwAo3PpwIhaxQ=; b=pvaWra2q1A6kIpW3QmRh99zM6JCWTNg0VduvkLU1qTWJmWJRpmF8P/PD4MQqCcPb8R bIXNjmMneKq9n+9Wen2YfvPHY0FpYvnU65U37qWNp/YmzbbqGjh3JG114Dsj39EWpm0m 8ZQiuSVrouFhKBADFeATq+ILRX3Bko8lXXNkq9X708Bu9FIiO5U09qZjjbT8ORGBVEtZ Qs335JudPMX8c1httFr8jVVTO6KqwU8D3TBHevYmSh9jSFDuPHpzgLhHkKq3JlfpsibV jcM05rPWIGdNcX47jFM8Eed5O7JGgpeeGLB/fUyv5oET7FnBjmwR9WK+fk764dGdY3yy Dbvw== X-Gm-Message-State: AOAM533i8b49MQh7n6HAkEerkCrz48aat/ZoQUrMUNvkxxJn/HopLO5I bjElcBsO/H5zrSKF/GZ//Iw= X-Google-Smtp-Source: ABdhPJwbWISOhBxGHptp1gqbym0Nispm2/sYDjzuafiWOdybNE26U+RSKaLXfRFGR5LNy22QDvJ4yg== X-Received: by 2002:a17:90a:bb8d:: with SMTP id v13mr24192531pjr.12.1615219094528; Mon, 08 Mar 2021 07:58:14 -0800 (PST) Received: from google.com ([2620:15c:211:201:4ccc:acdd:25da:14d1]) by smtp.gmail.com with ESMTPSA id f21sm9066040pjj.52.2021.03.08.07.58.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Mar 2021 07:58:13 -0800 (PST) Date: Mon, 8 Mar 2021 07:58:11 -0800 From: Minchan Kim To: Michal Hocko Cc: David Hildenbrand , Andrew Morton , linux-mm , LKML , joaodias@google.com Subject: Re: [PATCH] mm: be more verbose for alloc_contig_range faliures Message-ID: References: <9f7b4b8a-5317-e382-7f21-01667e017982@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: gg19wq3mzarinu1zufyumuj4sfnoqpdt X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: F36B04080F45 Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf17; identity=mailfrom; envelope-from=""; helo=mail-pl1-f173.google.com; client-ip=209.85.214.173 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615219094-517265 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Mar 08, 2021 at 04:42:43PM +0100, Michal Hocko wrote: > On Mon 08-03-21 15:13:35, David Hildenbrand wrote: > > On 08.03.21 15:11, Michal Hocko wrote: > > > On Mon 08-03-21 14:22:12, David Hildenbrand wrote: > > > > On 08.03.21 13:49, Michal Hocko wrote: > > > [...] > > > > > Earlier in the discussion I have suggested dynamic debugging facility. > > > > > Documentation/admin-guide/dynamic-debug-howto.rst. Have you tried to > > > > > look into that direction? > > > > > > > > Did you see the previous mail this is based on: > > > > > > > > https://lkml.kernel.org/r/YEEUq8ZRn4WyYWVx@google.com > > > > > > > > I agree that "nofail" is misleading. Rather something like > > > > "dump_on_failure", just a better name :) > > > > > > Yeah, I have read through the email thread. I just do not get why we > > > cannot make it pr_debug() and add -DDYNAMIC_DEBUG_MODULE for > > > page_alloc.c (I haven't checked whether that is possible for built in > > > compile units, maybe it is not but from a quick seems it should). > > > > > > I really do not like this to be a part of the API. alloc_contig_range is > > > > Which API? > > Any level of the alloc_contig_range api because I strongly suspect that > once there is something on the lower levels there will be a push to have > it in the directly consumed api as well. Besides that I think this is > just a wrong way to approach the problem. > > > It does not affect alloc_contig_range() itself, it's used > > internally only. Sure, we could simply pr_debug() for each and every > > migration failure. As long as it's default-disabled, sure. > > > > I do agree that we should look into properly including this into the dynamic > > debugging ifrastructure. > > Yeah, unless we learn this is not feasible for some reason, which I do > not see right now, then let's just make it pr_debug with the runtime > control. What do you see the problem? It's the dynamic debugging facility to enable only when admin want to use it. Otherwise, it's nop unless is't not enabled. Furthermore, it doesn't need to invent custom dump_page implementation(including dump_page_owner) by chaning pr_debug. Could you clarify your requirement? https://lore.kernel.org/linux-mm/YEEUq8ZRn4WyYWVx@google.com/ Since David agreed to drop nofail option in the API, I will keep the URL patch.