From: Valentin Schneider <valentin.schneider@arm.com>
To: Qais Yousef <qais.yousef@arm.com>
Cc: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Patrick Bellasi <patrick.bellasi@matbug.net>,
Chris Redpath <chrid.redpath@arm.com>,
Lukasz Luba <lukasz.luba@arm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] sched/uclamp: Protect uclamp fast path code with static key
Date: Fri, 19 Jun 2020 19:52:32 +0100 [thread overview]
Message-ID: <jhjpn9udh2d.mognet@arm.com> (raw)
In-Reply-To: <20200619172524.y66a4hz6g6hr3thr@e107158-lin.cambridge.arm.com>
On 19/06/20 18:25, Qais Yousef wrote:
> On 06/19/20 16:17, Valentin Schneider wrote:
>
> [...]
>
>> > But here this is
>> > just extra churn.
>> >
>> > If an imbalance has happend this means either:
>> >
>> > 1. enqueue/dequeue_task() is imablanced itself
>> > 2. uclamp_update_active() calls dec without inc.
>> >
>> > If 1 happened we have more reasons to be worried about. For 2 the function
>> > takes task_rq_lock() and does dec/inc in obvious way.
>> >
>>
>> True. I won't argue over the feasibility of the scenarios we are currently
>> aware of, my point was that if they do happen, it's nice to have debug
>> helps in the right places as the final breakage can happen much further
>> downstream.
>>
>> FWIW I don't like the diff I suggested at all, but if we can come up with a
>> cleverer scheme I think we should do it, as per the above.
>
> There's the fact as well that this whole thing is to deal with potentially
> avoid doing anything that is stricly not necessary in the fast path.
>
> keep in mind that my patch of introducing the sysctl is not accepted yet
> because it introduces such thing, but in that case it's not a debug only
> feature. CONFIG_SCHED_DEBUG do get enabled by distros because it exports a lot
> of useful info.
Sigh, true, but they really shouldn't. The whole point of having
SCHED_WARN_ON() is that it's a no-op on !SCHED_DEBUG kernels, which should
be any "production" kernel :(
next prev parent reply other threads:[~2020-06-19 18:52 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-18 19:55 [PATCH 0/2] sched: Optionally skip uclamp logic in fast path Qais Yousef
2020-06-18 19:55 ` [PATCH 1/2] sched/uclamp: Fix initialization of strut uclamp_rq Qais Yousef
2020-06-19 10:36 ` Valentin Schneider
2020-06-19 17:30 ` Peter Zijlstra
2020-06-19 17:39 ` Qais Yousef
2020-06-19 18:13 ` Peter Zijlstra
2020-06-19 18:42 ` Qais Yousef
2020-06-22 10:30 ` Qais Yousef
2020-06-18 19:55 ` [PATCH 2/2] sched/uclamp: Protect uclamp fast path code with static key Qais Yousef
2020-06-19 0:09 ` kernel test robot
2020-06-19 0:09 ` [RFC PATCH] sched/uclamp: sched_uclamp_unused can be static kernel test robot
2020-06-19 10:36 ` [PATCH 2/2] sched/uclamp: Protect uclamp fast path code with static key Valentin Schneider
2020-06-19 11:57 ` Mel Gorman
2020-06-19 12:17 ` Valentin Schneider
2020-06-19 12:55 ` Qais Yousef
2020-06-19 14:51 ` Qais Yousef
2020-06-19 12:51 ` Qais Yousef
2020-06-19 13:23 ` Steven Rostedt
2020-06-19 13:25 ` Valentin Schneider
2020-06-19 14:13 ` Qais Yousef
2020-06-19 15:17 ` Valentin Schneider
2020-06-19 17:25 ` Qais Yousef
2020-06-19 18:52 ` Valentin Schneider [this message]
2020-06-19 19:47 ` Peter Zijlstra
2020-06-19 10:39 ` Valentin Schneider
2020-06-19 17:45 ` Peter Zijlstra
2020-06-19 17:53 ` Qais Yousef
2020-06-22 9:06 ` [PATCH 0/2] sched: Optionally skip uclamp logic in fast path Lukasz Luba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jhjpn9udh2d.mognet@arm.com \
--to=valentin.schneider@arm.com \
--cc=bsegall@google.com \
--cc=chrid.redpath@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=patrick.bellasi@matbug.net \
--cc=peterz@infradead.org \
--cc=qais.yousef@arm.com \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.