[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YqzlL26IGdIHczaj@google.com>
Date: Fri, 17 Jun 2022 13:33:51 -0700
From: Brian Norris <briannorris@...omium.org>
To: Valentin Schneider <vschneid@...hat.com>
Cc: Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Juri Lelli <juri.lelli@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Ben Segall <bsegall@...gle.com>, linux-kernel@...r.kernel.org,
Dietmar Eggemann <dietmar.eggemann@....com>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Mel Gorman <mgorman@...e.de>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH] sched: Drop outdated compile-optimization comment
On Fri, Jun 17, 2022 at 12:10:05PM +0100, Valentin Schneider wrote:
> I'd argue that comment is still somewhat relevant but it applies to that
> block:
>
> #ifdef CONFIG_HAVE_SCHED_AVG_IRQ
> if ((irq_delta + steal) && sched_feat(NONTASK_CAPACITY))
> update_irq_load_avg(rq, irq_delta + steal);
> #endif
Eh, I suppose. The confusion still stands though ;)
> if !CONFIG_HAVE_SCHED_AVG_IRQ then yes you'd expect the compiler to not
> even add a call to update_irq_load_avg() in there, but compilers aren't the
> most trustworthy things :-) If you feel like it, you could play with
> GCC/clang and see what they emit if you remove those #ifdefs.
FWIW, update_irq_load_avg() is just "return 0" in that case. I think
that'd be considered excessive paranoia if you think a modern compiler
would still somehow produce a suboptimal result for that case :)
But anyway, I tried CONFIG_IRQ_TIME_ACCOUNTING=n +
CONFIG_PARAVIRT_TIME_ACCOUNTING=n with these compilers:
x86 gcc 11.2.0 (Debian)
x86 clang 13.0.1 (Debian)
aarch64-linux-gnu-gcc 11.2.0 (Debian)
and they all dropped the update_irq_load_avg() even without the #ifdef.
I'll drop it in a v2, since that seems to be the consensus.
Brian
Powered by blists - more mailing lists