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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 B31CAC3F2D1 for ; Thu, 5 Mar 2020 16:09:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 76E6F2146E for ; Thu, 5 Mar 2020 16:09:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=cmpxchg-org.20150623.gappssmtp.com header.i=@cmpxchg-org.20150623.gappssmtp.com header.b="O+9wu3Bf" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 76E6F2146E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 112286B0005; Thu, 5 Mar 2020 11:09:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 09C1D6B0006; Thu, 5 Mar 2020 11:09:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA5006B0007; Thu, 5 Mar 2020 11:09:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0101.hostedemail.com [216.40.44.101]) by kanga.kvack.org (Postfix) with ESMTP id CDA976B0005 for ; Thu, 5 Mar 2020 11:09:32 -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 981DB181AC9C6 for ; Thu, 5 Mar 2020 16:09:32 +0000 (UTC) X-FDA: 76561793784.28.ghost14_53437fac83300 X-HE-Tag: ghost14_53437fac83300 X-Filterd-Recvd-Size: 5268 Received: from mail-qv1-f66.google.com (mail-qv1-f66.google.com [209.85.219.66]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Thu, 5 Mar 2020 16:09:32 +0000 (UTC) Received: by mail-qv1-f66.google.com with SMTP id e7so2649000qvy.9 for ; Thu, 05 Mar 2020 08:09:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=YFJQskCNWVXuMbTVUr/PuWgn4wVuFnn3nZZ9fMSzuBk=; b=O+9wu3BfAMHUjSBZqShEq7hMfSVcLTfHQH3cPXWeDLhMdWns+lMT2fjlIuVY1xcidZ r4aOTQjLqDmz1oGNL0DlWKypSa0m3yZsnU98baSb735BbZLpwMdBa8ezdluL9EQhAfjQ WrqEGLIjEEzTA76rzJUhPVQYxwdyqC/HlQ5i15gGol/dcdcCgy5ZTMSn9xCotqoHeL/z LVSdPNoJnFMfy2TqYVXGDzx2e2K2xAWeZ4P34/1bZNcK28XlUjpfu0FAZ5QWJBKKgIRG 8xBuG8dS2XEPA3p/3jNDBn8jVaTwqUBnDUKjRsG9drVZQl30An7O+5aTkA+ooVkatlL1 ceLg== 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:content-transfer-encoding :in-reply-to; bh=YFJQskCNWVXuMbTVUr/PuWgn4wVuFnn3nZZ9fMSzuBk=; b=buzzzpoaKntkcjnkau78zIRLtd2qFhL2GI/g0dP0b0COSyliakJHO5AD94m0yTCwgE qPr5DNCt5DtF8nQnX0TU3FP1NxHeECFnzgCBopGMAsUAnzLuL1dzVFALNkxSQnxbyEKG HjCgx19SL4dUNhhGgL8c8SKkx5LtzulatCuqylwyNcfDW6V2xinE62fcWkv51MlXEEDX nIff5ULXc9Aqvkc3EMWd7s+WhiJ+alS5z9GMbqDr+0hKM4tCBZqWNN5qh9jN7VbErziH y4p9dDc4olnrltrLqKlsbMNbQRSwEKVjgPDzS6JVbVPXeF6xUwlynGrP6nd1XSvtMoxX YdxA== X-Gm-Message-State: ANhLgQ1Bf6WXbWgKFn31kS6oVEAd+0q4J9Mebe6C8O9QAPwlnRdcMzYP dXu80Tmrff+IkbEcqcRS0Zwlxw== X-Google-Smtp-Source: ADFU+vtZefeykjoi6XK4ZnTYc/+LRGud/nqzFl3SaKgi4mOWBmWqaGlmlg6yNMVJUNRNWWa06BMDeQ== X-Received: by 2002:ad4:510f:: with SMTP id g15mr7140943qvp.105.1583424571027; Thu, 05 Mar 2020 08:09:31 -0800 (PST) Received: from localhost (pool-96-232-200-60.nycmny.fios.verizon.net. [96.232.200.60]) by smtp.gmail.com with ESMTPSA id j1sm13031066qtd.66.2020.03.05.08.09.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Mar 2020 08:09:30 -0800 (PST) Date: Thu, 5 Mar 2020 11:09:29 -0500 From: Johannes Weiner To: Vincenzo Frascino Cc: Michal Hocko , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Vladimir Davydov , Andrew Morton Subject: Re: [PATCH] mm: Make mem_cgroup_id_get_many dependent on MMU and MEMCG_SWAP Message-ID: <20200305160929.GA1166@cmpxchg.org> References: <20200304142348.48167-1-vincenzo.frascino@arm.com> <20200304165336.GO16139@dhcp22.suse.cz> <8c489836-b824-184e-7cfe-25e55ab73000@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <8c489836-b824-184e-7cfe-25e55ab73000@arm.com> Content-Transfer-Encoding: quoted-printable 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 05, 2020 at 09:49:23AM +0000, Vincenzo Frascino wrote: > Hi Michal, >=20 > On 3/4/20 4:53 PM, Michal Hocko wrote: > > On Wed 04-03-20 14:23:48, Vincenzo Frascino wrote: > >> mem_cgroup_id_get_many() is currently used only when MMU or MEMCG_SW= AP > >> configuration options are enabled. Having them disabled triggers the > >> following warning at compile time: > >> > >> linux/mm/memcontrol.c:4797:13: warning: =E2=80=98mem_cgroup_id_get_m= any=E2=80=99 defined > >> but not used [-Wunused-function] > >> static void mem_cgroup_id_get_many(struct mem_cgroup *memcg, unsign= ed > >> int n) > >> > >> Make mem_cgroup_id_get_many() dependent on MMU and MEMCG_SWAP to add= ress > >> the issue. > >=20 > > A similar patch has been proposed recently > > http://lkml.kernel.org/r/87fthjh2ib.wl-kuninori.morimoto.gx@renesas.c= om. > > The conclusion was that the warning is not really worth adding code. > >=20 >=20 > Thank you for pointing this out, I was not aware of it. I understand th= at you > are against "#ifdeffery" in this case, but isn't it the case of adding = at least > __maybe_unused? This would prevent people from reporting it over and ov= er again > and you to have to push them back :) Let me know what do you think, in = case I am > happy to change my patch accordingly. I would ack a patch that adds __maybe_unused. This is a tiny function. If we keep it around a few releases after removing the last user, it costs us absolutely nothing. Eventually somebody will notice and send a patch to remove it. No big deal. There is, however, real cost in keeping bogus warnings around and telling people to ignore them. It's actively lowering the signal-to-noise ratio and normalizing warnings to developers. That's the kind of thing that will actually hide problems in the kernel. We know that the function can be unused in certain scenarios. It's silly to let the compiler continue to warn about it. That's exactly what __maybe_unused is for, so let's use it here.