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=-2.5 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 BEB4EC43603 for ; Tue, 17 Dec 2019 15:46:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 89E882465E for ; Tue, 17 Dec 2019 15:46:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 89E882465E 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 1F1238E008C; Tue, 17 Dec 2019 10:46:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1A1BF8E0079; Tue, 17 Dec 2019 10:46:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0905B8E008C; Tue, 17 Dec 2019 10:46:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0254.hostedemail.com [216.40.44.254]) by kanga.kvack.org (Postfix) with ESMTP id E61CD8E0079 for ; Tue, 17 Dec 2019 10:46:36 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 99F041CDD for ; Tue, 17 Dec 2019 15:46:36 +0000 (UTC) X-FDA: 76275060792.20.snail75_56c2312ed7a01 X-HE-Tag: snail75_56c2312ed7a01 X-Filterd-Recvd-Size: 5138 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Tue, 17 Dec 2019 15:46:36 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id c14so11836502wrn.7 for ; Tue, 17 Dec 2019 07:46:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=TuQqZHZA7F8zrUioSoTgrl1c8FOUxjce+qXhdDt9T1Q=; b=jAaxGhKeVvfilBapgHoGv9EZNYpMqzzftMYMfeqEIPD4p/6E0uUxfNiX37Hr4WlTI0 CoItAVfNB2oIE8L5iGeVZXaXaOXOylQf3xEi0nhN4xEXWQmxqMeDjMWAL9OilthdJp8j XtS4NyA2cPkT55YUXRni5ae2XkBMisX4MsHVH0s2bTxOK0qFzlFWaW0vjfQyF2mvWwA8 M0KPUz1ocuIW2xKhjYXGKlAfXJqT26XPs4eoxMZnfiUeHtIzcl0kz4DeyaxIz21DRWsZ W7ZzVHRFXRyZzUVkBpUj3yzvfLlHAyLydAgfZysJBcoAyXwPRJuuJpdpXPCPs3A7fUIi n7Vw== X-Gm-Message-State: APjAAAUPtzkmKkjXygiL47DweBnwR4elZUbZ2vf5qz4TSgOIbnWE1EhO jmWZYkuKW1XuTEJq17F6yHQ= X-Google-Smtp-Source: APXvYqyaLlXC8wOzGI//HEchY8EnBI7KhMkSmqaaisJZeWL/y3zxtl1RZBwyNF+AYAa4cVtyJryIXw== X-Received: by 2002:adf:f2d0:: with SMTP id d16mr36372586wrp.110.1576597595052; Tue, 17 Dec 2019 07:46:35 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id z8sm26075799wrq.22.2019.12.17.07.46.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Dec 2019 07:46:34 -0800 (PST) Date: Tue, 17 Dec 2019 16:46:33 +0100 From: Michal Hocko To: Chris Down Cc: Qian Cai , Kuninori Morimoto , Johannes Weiner , Vladimir Davydov , Andrew Morton , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: memcontrol.c: move mem_cgroup_id_get_many under CONFIG_MMU Message-ID: <20191217154633.GE7272@dhcp22.suse.cz> References: <20191217135440.GB58496@chrisdown.name> <392D7C59-5538-4A9B-8974-DB0B64880C2C@lca.pw> <20191217144652.GA7272@dhcp22.suse.cz> <20191217150921.GA136178@chrisdown.name> <20191217151931.GD7272@dhcp22.suse.cz> <20191217152814.GB136178@chrisdown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191217152814.GB136178@chrisdown.name> User-Agent: Mutt/1.12.2 (2019-09-21) 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 Tue 17-12-19 15:28:14, Chris Down wrote: > Michal Hocko writes: > > On Tue 17-12-19 15:09:21, Chris Down wrote: > > [...] > > > (Side note: I'm moderately baffled that a tightly scoped __maybe_unused is > > > considered sinister but somehow disabling -Wunused-function is on the table > > > :-)) > > > > Well, I usually do not like to see __maybe_unused because that is prone > > to bit-rot and loses its usefulness. Looking into the recent git logs > > most -Wunused-function led to the code removal (which is really good > > but the compiler is likely to do that already so the overall impact is > > not that large) or more ifdefery. I do not really see many instance of > > __maybe_unused. > > Hmm, but __maybe_unused is easy to find and document the reasons behind > nearby, and then reevaluate at some later time. On the other hand, it's much > *harder* to reevaluate which functions actually are unused in the long term > if we remove -Wunused-function, because enabling it to find candidates will > result in an incredibly amount of noise from those who have missed unused > functions previously due to the lack of the warning. I usually git grep for the function and that covers many cases. But realistically, I am more than skeptical people are going to do a regular cleanup like that. And that is the biggest deal with this annotation. Once it gets marked it will just stay that way and potentially get really unused eventually. So the overall benefit is close the zero in that case. Maybe dropping -Wunused-function is an overreaction. Git log shows there has been some code removed which is probably the most viable reaction to those reports. Maybe we just want to add those for W=1 or something like that. > Maybe Qian is right and we should just ignore such patches, but I think that > comes with its own risks that we will alienate perfectly well intentioned > new contributors to mm without them having any idea why we did that. I believe that both possitive and negative reaction to _any_ patch has to be properly justified - same applies to the patch itself. A warning report/fix is not an expcetion. In this particular case it has been pointed out that the reported function is a general purpose one which just happens to be used only for CONFIG_SWAP (rather than CONFIG_MMU) and using additional ifdeferry is likely not going to help long term. -- Michal Hocko SUSE Labs