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=-13.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 C7BE0C433E0 for ; Thu, 11 Mar 2021 19:27:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 15B7064F0E for ; Thu, 11 Mar 2021 19:27:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 15B7064F0E 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 71A568D02F2; Thu, 11 Mar 2021 14:27:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C9F78D02B2; Thu, 11 Mar 2021 14:27:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 543218D02F2; Thu, 11 Mar 2021 14:27:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0141.hostedemail.com [216.40.44.141]) by kanga.kvack.org (Postfix) with ESMTP id 345C78D02B2 for ; Thu, 11 Mar 2021 14:27:50 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id D462A52AA for ; Thu, 11 Mar 2021 19:27:49 +0000 (UTC) X-FDA: 77908578258.08.C72CB84 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by imf28.hostedemail.com (Postfix) with ESMTP id 4EAA3200038C for ; Thu, 11 Mar 2021 19:27:50 +0000 (UTC) Received: by mail-pj1-f51.google.com with SMTP id a22-20020a17090aa516b02900c1215e9b33so9565249pjq.5 for ; Thu, 11 Mar 2021 11:27:48 -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=di7TxN9U126MSsXtqlFQMHE0KdPDQyfURh79C8JPP0U=; b=TVRq0bZ2FraysW+EuxxHMyYW2TT1gIy6UzaA7mf8P9r6gheonkItJbRnC+mzH4DVh4 BrCjw+aURdQiNTr+sFBxWZu6oMNl5Twn2dfHo9oB6yeueNk2ZFl1CKZDBFPrsjfJG5lb owdY409itZQWQd3iGWHk3+VDPgTZX4I3VPu9TFqCf7tnTsmtq2/JiWKll2+Xhu8kQGAU ZZBmykwbelU54pjljgevY6MSeOpiur863A12VyyeqNbds6WXXf2NJaGFSRHhHjlGW5BN 6SfdUaGOR0yD9RLQE+ojIQVKGgpcbh2CwkVBmAnebNwayWxv3LSfu6a0p/LlnPiMefl3 b/uQ== 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=di7TxN9U126MSsXtqlFQMHE0KdPDQyfURh79C8JPP0U=; b=A2XrGbBoVbCQgd70TEyf/xX/qHAiDUrIAOL2SVmCKijcV1nw1UlySvRoN8K76pm/oF O5RDPMFUWXq7KUbyzsJ4gOHdDp+P0+2wmzxUCm364Gm39e/HB7jtLkZbh/1ynYRKjMzs LpRq6rGMAGGFObrUfZqzVrdGPPweKI4sY+xH75sIU4GG0vNSGf/bnmvuQklgkntv2Wu7 USqkFdSAawV4tpskHsfDQMxi4JcqJMitddiFHUPwiGowVuj8julzhrRynjdKUYW0tCTA fvl2ZqWO108SkxjlLoKirnEpcEBjbYCYsOYcayjr1g59/gv9YpzI1HEtvajSOGgpwxZo S7Dg== X-Gm-Message-State: AOAM530r4dHblUkHNyqmp3Wlwo+o9NoBGH0rhc6gz38MEBAuNdf30iG4 6ALdZZyp+yHw07S6obZEh7BAbzeeduQ= X-Google-Smtp-Source: ABdhPJxTCSt6l5a1HplytmRfVdIODJI7BtuMtW4z7hsoBorfmlcBoPYhRytrHlcIa2XqjPO0Jd2urg== X-Received: by 2002:a17:903:1242:b029:e0:3263:1693 with SMTP id u2-20020a1709031242b02900e032631693mr9871609plh.33.1615490868099; Thu, 11 Mar 2021 11:27:48 -0800 (PST) Received: from google.com ([2620:15c:211:201:64cb:74c7:f2c:e5e0]) by smtp.gmail.com with ESMTPSA id y68sm3498281pgy.5.2021.03.11.11.27.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Mar 2021 11:27:47 -0800 (PST) Date: Thu, 11 Mar 2021 11:27:45 -0800 From: Minchan Kim To: David Hildenbrand Cc: Andrew Morton , linux-mm , LKML , John Dias , Michal Hocko , Jason Baron Subject: Re: [PATCH v4] mm: page_alloc: dump migrate-failed pages Message-ID: References: <20210311183047.805891-1-minchan@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 4EAA3200038C X-Stat-Signature: p14t1m3qrgdybmzzywk9ahy1wg18nc6r Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf28; identity=mailfrom; envelope-from=""; helo=mail-pj1-f51.google.com; client-ip=209.85.216.51 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615490870-618108 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 Thu, Mar 11, 2021 at 07:53:01PM +0100, David Hildenbrand wrote: > On 11.03.21 19:30, Minchan Kim wrote: > > Currently, debugging CMA allocation failures is quite limited. > > The most commong source of these failures seems to be page > > s/commong/common/ Oops. > > > migration which doesn't provide any useful information on the > > reason of the failure by itself. alloc_contig_range can report > > those failures as it holds a list of migrate-failed pages. > > > > page refcount, mapcount with page flags on dump_page are > > helpful information to deduce the culprit. Furthermore, > > dump_page_owner was super helpful to find long term pinner > > who initiated the page allocation. > > Maybe simply "The information logged by dump_page() has already proven > helpful for debugging allocation issues, like identifying long-term pinnings > on ZONE_MOVABLE or MIGRATE_CMA." Will take it. > > > > > The reason it approach with dynamic debug is the debug message > > could emit lots of noises as alloc_contig_range calls more > > frequently since it's a best effort allocator. > > "Let's use the dynamic debugging infrastructure, such that we avoid > flooding the logs and creating a lot of noise on frequent > alloc_contig_range() calls. This information is helpful for debugging only." Sure. > > >>> > > > > > There are two ifdefery conditions to support common dyndbg options: > > > > - CONFIG_DYNAMIC_DEBUG_CORE && DYNAMIC_DEBUG_MODULE > > It aims for supporting the feature with only specific file > > with adding ccflags. > > > > - CONFIG_DYNAMIC_DEBUG > > It aims for supporting the feature with system wide globally. > > > > A simple example to enable the feature: > > > > Admin could enable the dump like this(by default, disabled) > > > > echo "func alloc_contig_dump_pages +p" > control > > > > Admin could disable it. > > > > echo "func alloc_contig_dump_pages =_" > control > > > > Detail goes Documentation/admin-guide/dynamic-debug-howto.rst > > <<< I'd drop that completely and only mention: > > "For details on dynamic debugging, see > Documentation/admin-guide/dynamic-debug-howto.rst." I'd like to keep it since many developer are not familiar with dynamic debug and the syntax was not straightforward to me when I read the doc. I believe that's why Andrew asked me to add simple comment on the comment. Including simple how to use in the description makes reviewer more comfortable to start the detail doc if they want to read and test. > > As you have usage in the code itself, I think you don't have to be > repetitive. The ifdeffery seems to be common (e.g., > include/linux/netdevice.) for dynamic debugging users, so I don't see the > need to describe that in detail. > > >>> > > > > > A concern is utility functions in dump_page uses inconsistent > > loglevels. > > > > __dump_page: KERN_WARNING > > __dump_page_owner: KERN_ALERT > > stack_trace_print: KERN_DEFAULT > > > > There are bunch of places to use the inconsistent loglevel > > utility functions(e.g., just grep dump_page/strace_trace_print). > > It's unfortunate but here we are. It could be addressed > > different patchset. > > <<< I'd drop that completely and mention > > "In the future, we might want to make the loglevels used inside dump_page() > consistent and eventually rework the way we log the information here. See > [1]" > > Where [1] is a link to the discussion. > > > > > Signed-off-by: Minchan Kim > > --- > > * from v3 - https://lore.kernel.org/linux-mm/20210310180104.517886-1-minchan@kernel.org > > * add dyndgb usage comment - akpm > > * use dumpstack instead of warn_on - david > > > > * from v2 - https://lore.kernel.org/linux-mm/20210308202047.1903802-1-minchan@kernel.org/ > > * remove ratelimit - mhocko > > > > * from v1 - https://lore.kernel.org/linux-mm/20210217163603.429062-1-minchan@kernel.org/ > > * use dynamic debugging with system wide instead of per-call site - mhocko > > > > mm/page_alloc.c | 31 +++++++++++++++++++++++++++++++ > > 1 file changed, 31 insertions(+) > > > > Minor nits: > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > index 3e4b29ee2b1e..76fc202cb105 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -8453,6 +8453,36 @@ static unsigned long pfn_max_align_up(unsigned long pfn) > > pageblock_nr_pages)); > > } > > +#if defined(CONFIG_DYNAMIC_DEBUG) || \ > > + (defined(CONFIG_DYNAMIC_DEBUG_CORE) && defined(DYNAMIC_DEBUG_MODULE)) > > +/* > > + * usage) > > "usage)" looks wrong here. Did you mean "Usage:" Sure. > > > + * dyndbg_dir="/sys/kernel/debug/dynamic_debug" > > + * To enable: > > + * echo "func alloc_contig_dump_pages +p" > $dyndbg_dir/control > > + * To disable: > > + * echo "func alloc_contig_dump_pages =_" > $dyndbg_dir/control > > + * For detail, read dynamic-debug-howto.rst > > Maybe simply > > "See admin-guide/dynamic-debug-howto.rst" Yes, for code comment, it would be enough to point out where the detail is. > > > + */ > > +static void alloc_contig_dump_pages(struct list_head *page_list) > > +{ > > + DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, > > + "migrate failure"); > > You can fit that into a single line. Sure. > > > + > > + if (DYNAMIC_DEBUG_BRANCH(descriptor)) { > > + struct page *page; > > + > > + dump_stack(); > > + list_for_each_entry(page, page_list, lru) > > + dump_page(page, "migration failure"); > > + } > > +} > > +#else > > +static inline void alloc_contig_dump_pages(struct list_head *page_list) > > +{ > > +} > > +#endif > > + > > /* [start, end) must belong to a single zone. */ > > static int __alloc_contig_migrate_range(struct compact_control *cc, > > unsigned long start, unsigned long end) > > @@ -8496,6 +8526,7 @@ static int __alloc_contig_migrate_range(struct compact_control *cc, > > NULL, (unsigned long)&mtc, cc->mode, MR_CONTIG_RANGE); > > } > > if (ret < 0) { > > + alloc_contig_dump_pages(&cc->migratepages); > > putback_movable_pages(&cc->migratepages); > > return ret; > > } > > > > As I said, for my taste good enough for now. I would certainly preferred > what Michal suggested (e.g., doing it via debug loglevels), but this gets Sure, that is definitely improvement. Someday, I will post the clean up. > the job done and is not too ugly. > > Reviewed-by: David Hildenbrand Thanks.