Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp7042747ybf; Fri, 6 Mar 2020 09:15:17 -0800 (PST) X-Google-Smtp-Source: ADFU+vue0XkSwLIYbRJ4+u8oDwjG6uCndlqteQlC2HYuBxjl7Unc7bUsNrOn4eBx2PcNoKOWdK5k X-Received: by 2002:a9d:19ef:: with SMTP id k102mr171522otk.220.1583514917487; Fri, 06 Mar 2020 09:15:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583514917; cv=none; d=google.com; s=arc-20160816; b=Hv5uynFVKnO5WhYhgQIfPnMjHQyCdL4bNwnAEAVhd/1JaigIUfzSilq/rWgGr+AQJ0 QyFFhi7uyhAiBF/JlENJCq+pTgiCtsPaSmB+B/NBg9zd6uR5eyZqjO0AVV7FEkQ/owyq k9XjFtWizpTWllTGQ/GC2SCVN8EOP0ZsJ2702H65w3q1BT87XTUq+DZhvj/oC/Aun7EP G1qIqg1dSNEXyIUEESiKaTFjWONCq3QHwU5wSi63qWfBb2nUY7RRHlEOrgudygmoHw/a DIywSksbFQuPdrbkxKnvHnCHjum60tXTtHKWNH98WVRYk2+0Yio50fK+aeiTHsGxiREj YNZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=CP2OVDyYeUQjbh/1nuCSOfSMlH1Bz55vOGR9t8SUcqE=; b=db3iBz8ExtTxo8DftClWgv1pNcHcKuq64spk27mtZ4BCuCh+kaeRWyXHiHIZDJNaDq RdAf+ePdBt5atTfLYnTlRNhg3u/E2A5tZOJQvHeNwU30QaLwuu5hDNi9kYpHu6TMSgFd RLUqaRxxqfIkzXD6rb+gDJwWCnzpmJ3+nZfWi8OsSX3YwGCy6G3ePymS6QETnQqRJHAW 84ZQYJt7HakCYJOIFA1gIyfBow03SkzLJ3B1xISj1rJCrStuiLjNSrDPuyaBhCLnSkPO j1g7V776HIKwRQsTSypap3idMAEBWhB4BuJ4I7JZsWWTiEKyLornVr0Db007UKPmLqAS PBig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Zb4P5gXN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o1si1668955otk.154.2020.03.06.09.14.59; Fri, 06 Mar 2020 09:15:17 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Zb4P5gXN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726485AbgCFROF (ORCPT + 99 others); Fri, 6 Mar 2020 12:14:05 -0500 Received: from mail-pg1-f195.google.com ([209.85.215.195]:33691 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726083AbgCFROF (ORCPT ); Fri, 6 Mar 2020 12:14:05 -0500 Received: by mail-pg1-f195.google.com with SMTP id m5so1375562pgg.0 for ; Fri, 06 Mar 2020 09:14:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CP2OVDyYeUQjbh/1nuCSOfSMlH1Bz55vOGR9t8SUcqE=; b=Zb4P5gXN1prnzjloUS4DQ0HPDzgguVvdcRh6yUnpOzJOW+wzrPOhKnrgRklnPijjw/ JI5yCY/BPUJ19qLbdl6We5Ie1/LM7tzqYETNQBJ43u1V4agoe/KFDcH2iG+m0zs9Zj4u zbSqAZxm7S6EEmFyeiUYQN1p5gpmHeznZAm2GOY5GAuTPnroLeJZ/upW4tWlo2zlTzPm qCnn9KW8HsxxSnBJMae375C3geAcjDjtWed9KgChpsInFgUKkCEDeTnloKACEhAfYIqK uY3NJTF0XQRLnJh4f04qH6FuDU0ErRUds6Ht/qEI5x92Er1Vors/WhGz10v4LNodOscs DmLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CP2OVDyYeUQjbh/1nuCSOfSMlH1Bz55vOGR9t8SUcqE=; b=Et1yxDfb+l0MGyf4DFpgJXmbBCFEqHHUK9aKPj2PJ5iXRLVoZDzc0YYCrw+ehHjpTR GH1ZaOiqf5DfaOg5rjDpiadlthiGscn6Wasey45yeK1kLgKnGeOS7rD0DSCmjM5r+dKM 8K6sBwvbCTAmOtywcGaw1d3YgnyderRDxjN8sg9GivzwD+YH/VBqjggei4Y/BcgkQi2j dHGlZuEi3d7FcBw3YZLDddEzSwsuK/3i4pdK2ylPLwX/qnnZq/sYX0dv/3+DNBFMdxqp molfIDnEWPX8jy2pKkr3eaQFFIT59UZXrTFAilrb6exDfMj1/UJialfKmjFVoLz0QhyB ZKCQ== X-Gm-Message-State: ANhLgQ35U1/59ynQwpvTf7lmgy0Yp6cnak/6Q/ppxfPJROD5Kv1Ucskj 5vxenjiqci5tE6x/n11hlyISAQ/8Av/jE03xdryQDw== X-Received: by 2002:a63:4d6:: with SMTP id 205mr4207108pge.10.1583514843107; Fri, 06 Mar 2020 09:14:03 -0800 (PST) MIME-Version: 1.0 References: <1583509304-28508-1-git-send-email-cai@lca.pw> In-Reply-To: <1583509304-28508-1-git-send-email-cai@lca.pw> From: Nick Desaulniers Date: Fri, 6 Mar 2020 09:13:52 -0800 Message-ID: Subject: Re: [PATCH] sched/cputime: silence a -Wunused-function warning To: Qian Cai Cc: Peter Zijlstra , Ingo Molnar , juri.lelli@redhat.com, Vincent Guittot , dietmar.eggemann@arm.com, Steven Rostedt , bsegall@google.com, mgorman@suse.de, LKML , clang-built-linux Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 6, 2020 at 7:42 AM Qian Cai wrote: > > account_other_time() is only used when CONFIG_IRQ_TIME_ACCOUNTING=y (in > irqtime_account_process_tick()) or CONFIG_VIRT_CPU_ACCOUNTING_GEN=y (in > get_vtime_delta()). When both are off, it will generate a compilation > warning from Clang, > > kernel/sched/cputime.c:255:19: warning: unused function > 'account_other_time' [-Wunused-function] > static inline u64 account_other_time(u64 max) > > Rather than wrapping around this function with a macro expression, > > if defined(CONFIG_IRQ_TIME_ACCOUNTING) || \ > defined(CONFIG_VIRT_CPU_ACCOUNTING_GEN) > > just use __maybe_unused for this small function which seems like a good > trade-off. > > Signed-off-by: Qian Cai Hi Qian, thanks for the patch! Generally, I'm not a fan of __maybe_unused. It is a tool in the toolbox for solving this issue, but it's my least favorite. Should the call sites be eliminated, this may mask an unused and entirely dead function from being removed. Preprocessor guards based on config give more context into *why* a particular function may be unused. So let's take a look at the call sites of account_other_time(). Looks like irqtime_account_process_tick() (guarded by CONFIG_IRQ_TIME_ACCOUNTING) and get_vtime_delta() (guarded by CONFIG_VIRT_CPU_ACCOUNTING_GEN). If it were one config guard, then I would prefer to move the definition to be within the same guard, just before the function definition that calls it, but we have a more complicated case here. The next thing I'd check to see is if there's a dependency between configs. In this case, both CONFIG_IRQ_TIME_ACCOUNTING and CONFIG_VIRT_CPU_ACCOUNTING_GEN are defined in init/Kconfig. In this case there's also no dependency between configs, so specifying one doesn't imply the other; so guarding on one of the two configs is also not an option. So, as much as I'm not a fan of __maybe_unused, it is indeed the simplest option. Though, I'd still prefer the ifdef you describe instead, maybe the maintainers can provide guidance/preference? Otherwise, Reviewed-by: Nick Desaulniers > --- > kernel/sched/cputime.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c > index cff3e656566d..85da4d6dee24 100644 > --- a/kernel/sched/cputime.c > +++ b/kernel/sched/cputime.c > @@ -252,7 +252,7 @@ static __always_inline u64 steal_account_process_time(u64 maxtime) > /* > * Account how much elapsed time was spent in steal, irq, or softirq time. > */ > -static inline u64 account_other_time(u64 max) > +static inline __maybe_unused u64 account_other_time(u64 max) > { > u64 accounted; > > -- -- Thanks, ~Nick Desaulniers