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 74E5AC433E6 for ; Mon, 8 Mar 2021 17:01:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 03D6E64FB8 for ; Mon, 8 Mar 2021 17:01:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 03D6E64FB8 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 84D166B00A6; Mon, 8 Mar 2021 12:01:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7FDCB8D0052; Mon, 8 Mar 2021 12:01:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 650AC8D001D; Mon, 8 Mar 2021 12:01:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0203.hostedemail.com [216.40.44.203]) by kanga.kvack.org (Postfix) with ESMTP id 44D7E6B00A6 for ; Mon, 8 Mar 2021 12:01:16 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 05ED7824999B for ; Mon, 8 Mar 2021 17:01:16 +0000 (UTC) X-FDA: 77897322552.20.0BAF8A4 Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) by imf14.hostedemail.com (Postfix) with ESMTP id 7192BC0007E0 for ; Mon, 8 Mar 2021 17:01:11 +0000 (UTC) Received: by mail-pj1-f43.google.com with SMTP id kx1so3366656pjb.3 for ; Mon, 08 Mar 2021 09:01: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=Ru9F9a1RhouEc909fqeCnbgCPw/G1uUji7fWjGwbaOg=; b=KKzp7+2SxHvXKPm1hyNkSAS7wxCgpnIjs1BUg20f0lPhBFp1IwyvcGE9m1bS56w7pk UOjdqzl9K9fIHu/lWBWufp7mPBkQL5/ZPaNhkgX0mnrNbbNwsr0mYEscwDYCxRLT3pCL UU03On7NfppXE3EzohKRuSxc6kX8F6v+nwYrrmnhSjPDTF3rAfBk3ks50GkR3mkBFzmB CHhl8v2QyvstKFf7hBguIfVwJo5soU/Kxszgf6qVx0lOUBN792/5QGQafjrbxg3W7WlZ 82jem2xrjSmHToTgIkT4PNW+7XsduwkpKileEg8U9OtO8Mktf2mepoCjyKGENpI7N3ha Rq4w== 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=Ru9F9a1RhouEc909fqeCnbgCPw/G1uUji7fWjGwbaOg=; b=WJfzl4ZQ+bLtNB+2fVlFeGUMq+LrIGKkuIG1YQ5J42ZV+EjKm52sRhONbAi0XTaTRO hF8DmGGjCbcEoivQwsB9kgnZWnAHlRdltSzQW/R2W+CJo/dlcYajjfH484DqClWyaMlv Y7zmdrE1rDM0WE3lnywId1sTm/K8/+vkfs1CJNtijJZGV/l3eVIWi6CetZn05HRx4/te cw0jnHTKktsVF3yFYnzRxs8/k/7Ea2qUiNKZ9lwnOmE3Bz71fT0yrVm3YoGDVd61OJeh Voi5L09fTe0jnXY7lZAvvh9KIv0aVkWebp5ei2y+8+cJAAox3X0SuGDY8PkTQq9l1skA gUCg== X-Gm-Message-State: AOAM532ZQovk7aegtyyfbDnkmgq+2Y7+0fbfak9E2ZXQ+vNXFx7Qr0Ok 73EYKfrGGnIoNmBFcQcjGcI= X-Google-Smtp-Source: ABdhPJzEHivhZGe0/lB4cl+Z6AdcbpAosHSCSJInwdwzqUhIxbU10GipAmvszvlmpOIPX/dWtTH4Rg== X-Received: by 2002:a17:90a:a10c:: with SMTP id s12mr3800865pjp.166.1615222874153; Mon, 08 Mar 2021 09:01:14 -0800 (PST) Received: from google.com ([2620:15c:211:201:4ccc:acdd:25da:14d1]) by smtp.gmail.com with ESMTPSA id y9sm4956495pfl.201.2021.03.08.09.01.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Mar 2021 09:01:12 -0800 (PST) Date: Mon, 8 Mar 2021 09:01:10 -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-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 7192BC0007E0 X-Stat-Signature: eydn1o9o31scobpfxi1yxaiwb1k9n8o6 Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf14; identity=mailfrom; envelope-from=""; helo=mail-pj1-f43.google.com; client-ip=209.85.216.43 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615222871-601668 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 05:21:47PM +0100, Michal Hocko wrote: > On Mon 08-03-21 07:58:11, Minchan Kim wrote: > [...] > > 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/ > > I am not really sure this is the right way to enable dynamic logging. > Maybe it is. I thought we can go with something as simple as pr_debug. > You are right that we do not have dump_page with the kernel log level. > This is rather annoying but a) do we need a full dump_page functionality Most parts I take care of are pr_warn("page:%p refcount:%d mapcount:%d mapping:%p index:%#lx pfn:%#lx\n", page, page_ref_count(head), mapcount, mapping, page_to_pgoff(page), page_to_pfn(page)); pr_warn("%sflags: %#lx(%pGp)%s\n", type, head->flags, &head->flags, page_cma ? " CMA" : ""); And dump_page_owner which was super helpful to find GUP places. Looks like most of dump_pages. > and b) can we make it log level aware with the dynamic debug > infrastructure preserved? If not then then an explicit handling is If we could make aware of loglevel, we need to enable each by each IOW. IOW, what we want to enable is mm/page_alloc.c #1492 line, for example. However, we should enable mm/debug.c # 88 line mm/debug.c # 102 line mm/debug.c # 121 line mm/page_owner.c # 448 line mm/page_owner.c # 450 line kernel/stacktrace.c #32 line And so on. Furthermore, user should be aware of that how the kernel code is changed for those all sites and reconfigure and follow new added code. So, I choosed explict handling. > probably the only way and this should be reviewed by people who are more > familiar with that framework than me. > -- > Michal Hocko > SUSE Labs