[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200108095108.GA153171@google.com>
Date: Wed, 8 Jan 2020 09:51:08 +0000
From: Quentin Perret <qperret@...gle.com>
To: Dietmar Eggemann <dietmar.eggemann@....com>
Cc: Qais Yousef <qais.yousef@....com>, Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
Luis Chamberlain <mcgrof@...nel.org>,
Kees Cook <keescook@...omium.org>,
Iurii Zaikin <yzaikin@...gle.com>,
Juri Lelli <juri.lelli@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
valentin.schneider@....com,
Patrick Bellasi <patrick.bellasi@...bug.net>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
kernel-team@...roid.com
Subject: Re: [PATCH] sched/rt: Add a new sysctl to control uclamp_util_min
On Tuesday 07 Jan 2020 at 20:30:36 (+0100), Dietmar Eggemann wrote:
> On 07/01/2020 14:42, Quentin Perret wrote:
> > Hi Qais,
> >
> > On Friday 20 Dec 2019 at 16:48:38 (+0000), Qais Yousef wrote:
>
> [...]
>
> >> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
> >> index e591d40fd645..19572dfc175b 100644
> >> --- a/kernel/sched/rt.c
> >> +++ b/kernel/sched/rt.c
> >> @@ -2147,6 +2147,12 @@ static void pull_rt_task(struct rq *this_rq)
> >> */
> >> static void task_woken_rt(struct rq *rq, struct task_struct *p)
> >> {
> >> + /*
> >> + * When sysctl_sched_rt_uclamp_util_min value is changed by the user,
> >> + * we apply any new value on the next wakeup, which is here.
> >> + */
> >> + uclamp_rt_sync_default_util_min(p);
> >
> > The task has already been enqueued and sugov has been called by then I
> > think, so this is a bit late. You could do that in uclamp_rq_inc() maybe?
>
> That's probably better.
> Just to be sure ...we want this feature (an existing rt task gets its
> UCLAMP_MIN value set when the sysctl changes) because there could be rt
> tasks running before the sysctl is set?
Yeah, I was wondering the same thing, but I'd expect sysadmin to want
this. We could change the min clamp of existing RT tasks in userspace
instead, but given how simple Qais' lazy update code is, the in-kernel
looks reasonable to me. No strong opinion, though.
Thanks,
Quentin
Powered by blists - more mailing lists