Hi Dietmar!
On 14-Aug 17:44, Dietmar Eggemann wrote:
On 08/06/2018 06:39 PM, Patrick Bellasi wrote:
This one indicates that there are some holes in your ref-counting.
Not really, this has been added not because I've detected a refcount
issue... but because it was suggested as a possible safety check in a
previous code review comment:
https://lore.kernel.org/lkml/20180720151156.GA31421@e110439-lin/
It's probably easier to debug that there is still a task but the
uc_grp[group_id].tasks value == 0 (A). I assume the other problem exists as
well, i.e. last task and uc_grp[group_id].tasks > 1 (B)?
You have uclamp_cpu_[get/put](_id)() in [enqueue/dequeue]_task.
Patch 04/14 introduces its use in uclamp_task_update_active().
Do you know why (A) (and (B)) are happening?
I've never saw that warning in my tests so far so, again, the warning
is there just to support testing/debugging when refcounting code
is/will be touched in the future. That's also the reason why is
SCHED_DEBUG protected.
Here you right, I would say that it should always be:
clamp_value <= uc_cpu->value[clamp_id]
since this matches the update done at the end of uclamp_cpu_get_id():
if (uc_cpu->value[clamp_id] < clamp_value)
uc_cpu->value[clamp_id] = clamp_value;
Perhaps we can add another safety check here, similar to the one
above, to have something like:
clamp_value = uc_grp[group_id].value;
#ifdef SCHED_DEBUG
if (unlikely(clamp_value > uc_cpu->value[clamp_id])) {
WARN(1, "invalid CPU[%d] clamp group [%d:%d] value\n",
cpu_of(rq), clamp_id, group_id);
#endif
if (clamp_value == uc_cpu->value[clamp_id])
uclamp_cpu_update(rq, clamp_id);