Re: [PATCH v6 05/16] sched/core: uclamp: Update CPU's refcount on clamp changes
From: Peter Zijlstra <peterz@infradead.org>
Date: 2019-01-24 12:38:34
Also in:
linux-pm, lkml
On Thu, Jan 24, 2019 at 11:21:53AM +0000, Patrick Bellasi wrote:
When a task-specific uclamp value is changed for a task, instead, a dequeue/enqueue is not needed. As long as we are doing a lazy update, that sounds just like not necessary overhead.
When that overhead is shown to be a problem, is when we'll look at that :-)
However, there could still be value in keeping code consistent and if
you prefer it this way what should I do?
---8<---
__sched_setscheduler()
...
if (policy < 0)
policy = oldpolicy = p->policy;
...
if (unlikely(policy == p->policy)) {
...
if (uclamp_changed()) // Force dequeue/enqueue
goto change;
}
change:
...
if (queued)
dequeue_task(rq, p, queue_flags);
if (running)
put_prev_task(rq, p);
__setscheduler_uclamp();
__setscheduler(rq, p, attr, pi);
if (queued)
enqueue_task(rq, p, queue_flags);
if (running)
set_curr_task(rq, p);
...
---8<---
Could be something like that ok with you?Yes, that's about what I was expecting.
Not sure about side-effects on p->prio(): for CFS seems to be reset to NORMAL in this case :/
That's what we need KEEP_PARAM for, right?