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 BDBC7C433E0 for ; Mon, 8 Mar 2021 20:27:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5732E6528C for ; Mon, 8 Mar 2021 20:27:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5732E6528C 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 A7E268D0074; Mon, 8 Mar 2021 15:27:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A54E78D001D; Mon, 8 Mar 2021 15:27:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F6398D0074; Mon, 8 Mar 2021 15:27:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0029.hostedemail.com [216.40.44.29]) by kanga.kvack.org (Postfix) with ESMTP id 7453D8D001D for ; Mon, 8 Mar 2021 15:27:30 -0500 (EST) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 265F0180AD81D for ; Mon, 8 Mar 2021 20:27:30 +0000 (UTC) X-FDA: 77897842260.06.8B00E58 Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) by imf08.hostedemail.com (Postfix) with ESMTP id 546328019149 for ; Mon, 8 Mar 2021 20:27:24 +0000 (UTC) Received: by mail-pg1-f182.google.com with SMTP id w34so6110162pga.8 for ; Mon, 08 Mar 2021 12:27:29 -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=hRPr7bnVWx2uLZbAR2SmsL4C/BUZ3foyYS3yoqELctA=; b=CQ+22zVCKbytUwtlSHsq2hjwFobUy+C9SvYr9BU1S5e6NNM7CI9S+Pe0Z7CaEjt2nu Mgkz29NQvQD/LkysXDVMir8DsTKW82Yk0V2PC1j24ZvvihJu5seqMoo4LMs2MeE2Zb8Z RhBg29gAlMtrg+SwG+pzDgjpX6T5uRJd/p3yQRn6dPEtjnYh020mSMDt+djhVhmixOsI Xk4V1T//5txX1lhpofjI9MFOtF4tP+74zLBZhIp7I9mNAXGNuhoxPVakB0/SN73qsxIH s2Gi7VxtXxQlQwzj96/C97TuIGEEb9nl4r6JgbP2ZbQdXq7ctT6tNAOnoZxBL48Bq669 C4vQ== 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=hRPr7bnVWx2uLZbAR2SmsL4C/BUZ3foyYS3yoqELctA=; b=QcP3l+hByi+/gLfm+Yk9hzG3FWZVFiA7xfMtMSRvuKIUuCY6Oi0xiXiTqGjTc9t3D1 mrcOcdfIa9ZWXIRt8lvARU0/bgFF/Y0iP3gQIPfmrH5RhNjGDFVVoiunXmWtQVJTRNyZ jyRrGG3NatXhMjJZVFioWCTHa7MbU0E1xVDa0/a3KXakmAkXj8nrh7WM0kMCM/4Ed5Uj PY7BMvHmzJyoTjfomkrBr6cbH/AxR1Qu7XAK7w0kM62PfrIH5kSu4oRtGw5j6hQi7t1J /8IgsqU9GljEGzfTYrNBbMnyWaCZUDXWUNS98JpUfkfizFyczoI0xGvdRRwtgoXbShDM QNsg== X-Gm-Message-State: AOAM532VL0+CnBbzTsY8yxrBjFrHmKBSJTvIN6Hs/U1qNzxsIS67a/QG EVjKrR4LYVX+mVApIP+SESk= X-Google-Smtp-Source: ABdhPJxGj8Vm9an4DDqk0D1+m0qqdClAMlqRoMzd1HW58FTJNENo873vU0iPcZCzEor3g2Jeh95xaQ== X-Received: by 2002:a63:fa02:: with SMTP id y2mr21676670pgh.412.1615235248690; Mon, 08 Mar 2021 12:27:28 -0800 (PST) Received: from google.com ([2620:15c:211:201:4ccc:acdd:25da:14d1]) by smtp.gmail.com with ESMTPSA id 134sm11299449pfc.113.2021.03.08.12.27.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Mar 2021 12:27:27 -0800 (PST) Date: Mon, 8 Mar 2021 12:27:25 -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: 86cmjpjarxrux5ot8oezaztkuonwd34m X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 546328019149 Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf08; identity=mailfrom; envelope-from=""; helo=mail-pg1-f182.google.com; client-ip=209.85.215.182 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615235244-380262 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 07:58:11AM -0800, Minchan Kim wrote: > 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. I posted formal patch with Ccing dynamic debug maintainer. https://lore.kernel.org/linux-mm/20210308202047.1903802-1-minchan@kernel.org/ Let's discuss stuff related to dynamic debug there.