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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,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 57899C433DB for ; Mon, 8 Mar 2021 16:21:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CCFAA6521F for ; Mon, 8 Mar 2021 16:21:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CCFAA6521F Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5548E8D004B; Mon, 8 Mar 2021 11:21:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 506D78D001D; Mon, 8 Mar 2021 11:21:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3CE8D8D004B; Mon, 8 Mar 2021 11:21:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0156.hostedemail.com [216.40.44.156]) by kanga.kvack.org (Postfix) with ESMTP id 226F58D001D for ; Mon, 8 Mar 2021 11:21:52 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id C9583181AC9CC for ; Mon, 8 Mar 2021 16:21:51 +0000 (UTC) X-FDA: 77897223222.28.37E18F8 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf09.hostedemail.com (Postfix) with ESMTP id EFE4060024AD for ; Mon, 8 Mar 2021 16:21:47 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1615220508; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zmNh9XTFyds75r57idvI9IbPhvrQ/MrJNdhnTPn5J+g=; b=l16WpMgy1aCH2nY1Eh/uNbTgDBMvegb8xG2+5G1tx/NkwOX/b1Hiri3vpEFBNjSAx269P2 Ca62/brNi8VVLouYVPnxyaT4Di+dzVZ6zP7T8e30t97evwV/g+xHfyVAcaoD6ukNh4FIXh UTDkL2616zTigPQCi9r4xOyk/LUdz5g= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 22112ADE3; Mon, 8 Mar 2021 16:21:48 +0000 (UTC) Date: Mon, 8 Mar 2021 17:21:47 +0100 From: Michal Hocko To: Minchan Kim 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: a5tihgufig3zyeptpuusw318qceajs7p X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: EFE4060024AD Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf09; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615220507-717104 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 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 and b) can we make it log level aware with the dynamic debug infrastructure preserved? If not then then an explicit handling is probably the only way and this should be reviewed by people who are more familiar with that framework than me. -- Michal Hocko SUSE Labs