linux-kernel - Re: [PATCH] sched: update cpupri for runqueue when its priority changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1308417114.9218.220.camel@gandalf.stny.rr.com>
Date:	Sat, 18 Jun 2011 13:11:54 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Hillf Danton <dhillf@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Mike Galbraith <efault@....de>,
	Yong Zhang <yong.zhang0@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] sched: update cpupri for runqueue when its priority
 changes

On Sat, 2011-06-18 at 22:54 +0800, Hillf Danton wrote:

> >> diff --git a/kernel/sched_rt.c b/kernel/sched_rt.c
> >> index 08e9374..9508168 100644
> >> --- a/kernel/sched_rt.c
> >> +++ b/kernel/sched_rt.c
> >> @@ -1158,6 +1158,8 @@ static struct task_struct
> >> *pick_next_task_rt(struct rq *rq)
> >>          * lock again later if there is no need to push
> >>          */
> >>         rq->post_schedule = has_pushable_tasks(rq);
> >> +
> >> +       cpupri_set(&rq->rd->cpupri, rq->cpu, p == NULL ? MAX_RT_PRIO : p->prio);
> >
> > In pick_next_task_rt(), p is the highes prio that is queued. Thus,
> > cpupri is already set to p->prio. If p is NULL, then there is no rt
> > tasks queued on this rq, and cpupri is set to MAX_RT_PRIO. Your patch
> > here does not change anything.
> >
> 
> There are two cases that NULL is returned in _pick_next_task_rt(), it is the
> second case, after checking rt_rq->rt_nr_running, that is captured, and if
> NULL is returned in the second case, the CPU priority does change.

The two cases are:

1) no rt task exists
2) the runqueue is throttled.

We already talked about the throttled case. The case where no rt task
exists means that the last rt task has been dequeued. When that happens,
the cpupri is updated then. I don't see any bug. There's no need to
update cpupri at this point.

> 
> In another scenario that has little with {en, de}queue, as shown by
> requeue_task_rt(), the CPU priority will change if other RT tasks exist.
> 

The requeue_task_rt() does not change the priority of the CPU. It just
updates the task in its order of placement in the queue of other tasks
of the same priority.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/