Re: [Question] sched/rt_mutex: re-enqueue_task on rt_mutex_setprio()
On Mon, Jul 9, 2012 at 3:48 PM, Peter Zijlstra wrote:
> On Mon, 2012-07-09 at 09:50 +0900, Namhyung Kim wrote:
>> On Sat, 07 Jul 2012 21:29:19 -0400, Steven Rostedt wrote:
>> > On Sat, 2012-07-07 at 14:44 +0900, Namhyung Kim wrote:
>> >> Hi,
>> >>
>> >> I have a question on the code below:
>> >>
>> >> void rt_mutex_setprio(struct task_struct *p, int prio)
>> >> {
>> >> ...
>> >>if (on_rq)
>> >>enqueue_task(rq, p, oldprio < prio ? ENQUEUE_HEAD : 0);
>> >>
>> >> When enqueueing @p with new @prio, it seems put @p at the head of a
>> >> rq if appropriate. I guess it's the case of boosting @p with higher
>> >> priority, right?
>> >
>> > Actually, no. We put @p at the head of the queue when unboosting. If a
>> > task is going from a high priority into a lower priority, it is still
>> > treated as "important" for that priority, and is put to the front of the
>> > queue (it was just higher than everything else on that queue). But if we
>> > are boosting a task from a low priority, why put it to the head of other
>> > tasks of its new priority, when those tasks were just higher than this
>> > task, and this task is now just an "equal".
>>
>> Thanks for the explanation. (Isn't it worth getting commented?) :)
>
> Possibly, note that this part is well spec'ed by POSIX, see
>
> http://pubs.opengroup.org/onlinepubs/009695299/functions/xsh_chap02_08.html
>
> SCHED_FIFO.8
Thanks for the pointer. I need to educate myself a lot more!
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Question] sched/rt_mutex: re-enqueue_task on rt_mutex_setprio()
On Mon, 2012-07-09 at 09:50 +0900, Namhyung Kim wrote:
> On Sat, 07 Jul 2012 21:29:19 -0400, Steven Rostedt wrote:
> > On Sat, 2012-07-07 at 14:44 +0900, Namhyung Kim wrote:
> >> Hi,
> >>
> >> I have a question on the code below:
> >>
> >> void rt_mutex_setprio(struct task_struct *p, int prio)
> >> {
> >> ...
> >>if (on_rq)
> >>enqueue_task(rq, p, oldprio < prio ? ENQUEUE_HEAD : 0);
> >>
> >> When enqueueing @p with new @prio, it seems put @p at the head of a
> >> rq if appropriate. I guess it's the case of boosting @p with higher
> >> priority, right?
> >
> > Actually, no. We put @p at the head of the queue when unboosting. If a
> > task is going from a high priority into a lower priority, it is still
> > treated as "important" for that priority, and is put to the front of the
> > queue (it was just higher than everything else on that queue). But if we
> > are boosting a task from a low priority, why put it to the head of other
> > tasks of its new priority, when those tasks were just higher than this
> > task, and this task is now just an "equal".
>
> Thanks for the explanation. (Isn't it worth getting commented?) :)
Possibly, note that this part is well spec'ed by POSIX, see
http://pubs.opengroup.org/onlinepubs/009695299/functions/xsh_chap02_08.html
SCHED_FIFO.8
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Question] sched/rt_mutex: re-enqueue_task on rt_mutex_setprio()
On Mon, 2012-07-09 at 09:50 +0900, Namhyung Kim wrote:
On Sat, 07 Jul 2012 21:29:19 -0400, Steven Rostedt wrote:
On Sat, 2012-07-07 at 14:44 +0900, Namhyung Kim wrote:
Hi,
I have a question on the code below:
void rt_mutex_setprio(struct task_struct *p, int prio)
{
...
if (on_rq)
enqueue_task(rq, p, oldprio prio ? ENQUEUE_HEAD : 0);
When enqueueing @p with new @prio, it seems put @p at the head of a
rq if appropriate. I guess it's the case of boosting @p with higher
priority, right?
Actually, no. We put @p at the head of the queue when unboosting. If a
task is going from a high priority into a lower priority, it is still
treated as important for that priority, and is put to the front of the
queue (it was just higher than everything else on that queue). But if we
are boosting a task from a low priority, why put it to the head of other
tasks of its new priority, when those tasks were just higher than this
task, and this task is now just an equal.
Thanks for the explanation. (Isn't it worth getting commented?) :)
Possibly, note that this part is well spec'ed by POSIX, see
http://pubs.opengroup.org/onlinepubs/009695299/functions/xsh_chap02_08.html
SCHED_FIFO.8
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Question] sched/rt_mutex: re-enqueue_task on rt_mutex_setprio()
On Mon, Jul 9, 2012 at 3:48 PM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, 2012-07-09 at 09:50 +0900, Namhyung Kim wrote:
On Sat, 07 Jul 2012 21:29:19 -0400, Steven Rostedt wrote:
On Sat, 2012-07-07 at 14:44 +0900, Namhyung Kim wrote:
Hi,
I have a question on the code below:
void rt_mutex_setprio(struct task_struct *p, int prio)
{
...
if (on_rq)
enqueue_task(rq, p, oldprio prio ? ENQUEUE_HEAD : 0);
When enqueueing @p with new @prio, it seems put @p at the head of a
rq if appropriate. I guess it's the case of boosting @p with higher
priority, right?
Actually, no. We put @p at the head of the queue when unboosting. If a
task is going from a high priority into a lower priority, it is still
treated as important for that priority, and is put to the front of the
queue (it was just higher than everything else on that queue). But if we
are boosting a task from a low priority, why put it to the head of other
tasks of its new priority, when those tasks were just higher than this
task, and this task is now just an equal.
Thanks for the explanation. (Isn't it worth getting commented?) :)
Possibly, note that this part is well spec'ed by POSIX, see
http://pubs.opengroup.org/onlinepubs/009695299/functions/xsh_chap02_08.html
SCHED_FIFO.8
Thanks for the pointer. I need to educate myself a lot more!
Thanks,
Namhyung
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Question] sched/rt_mutex: re-enqueue_task on rt_mutex_setprio()
On Sat, 07 Jul 2012 21:29:19 -0400, Steven Rostedt wrote:
> On Sat, 2012-07-07 at 14:44 +0900, Namhyung Kim wrote:
>> Hi,
>>
>> I have a question on the code below:
>>
>> void rt_mutex_setprio(struct task_struct *p, int prio)
>> {
>> ...
>> if (on_rq)
>> enqueue_task(rq, p, oldprio < prio ? ENQUEUE_HEAD : 0);
>>
>> When enqueueing @p with new @prio, it seems put @p at the head of a
>> rq if appropriate. I guess it's the case of boosting @p with higher
>> priority, right?
>
> Actually, no. We put @p at the head of the queue when unboosting. If a
> task is going from a high priority into a lower priority, it is still
> treated as "important" for that priority, and is put to the front of the
> queue (it was just higher than everything else on that queue). But if we
> are boosting a task from a low priority, why put it to the head of other
> tasks of its new priority, when those tasks were just higher than this
> task, and this task is now just an "equal".
Thanks for the explanation. (Isn't it worth getting commented?) :)
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Question] sched/rt_mutex: re-enqueue_task on rt_mutex_setprio()
On Sat, 07 Jul 2012 21:29:19 -0400, Steven Rostedt wrote:
On Sat, 2012-07-07 at 14:44 +0900, Namhyung Kim wrote:
Hi,
I have a question on the code below:
void rt_mutex_setprio(struct task_struct *p, int prio)
{
...
if (on_rq)
enqueue_task(rq, p, oldprio prio ? ENQUEUE_HEAD : 0);
When enqueueing @p with new @prio, it seems put @p at the head of a
rq if appropriate. I guess it's the case of boosting @p with higher
priority, right?
Actually, no. We put @p at the head of the queue when unboosting. If a
task is going from a high priority into a lower priority, it is still
treated as important for that priority, and is put to the front of the
queue (it was just higher than everything else on that queue). But if we
are boosting a task from a low priority, why put it to the head of other
tasks of its new priority, when those tasks were just higher than this
task, and this task is now just an equal.
Thanks for the explanation. (Isn't it worth getting commented?) :)
Thanks,
Namhyung
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Question] sched/rt_mutex: re-enqueue_task on rt_mutex_setprio()
On Sat, 2012-07-07 at 14:44 +0900, Namhyung Kim wrote:
> Hi,
>
> I have a question on the code below:
>
> void rt_mutex_setprio(struct task_struct *p, int prio)
> {
> ...
> if (on_rq)
> enqueue_task(rq, p, oldprio < prio ? ENQUEUE_HEAD : 0);
>
> When enqueueing @p with new @prio, it seems put @p at the head of a
> rq if appropriate. I guess it's the case of boosting @p with higher
> priority, right?
Actually, no. We put @p at the head of the queue when unboosting. If a
task is going from a high priority into a lower priority, it is still
treated as "important" for that priority, and is put to the front of the
queue (it was just higher than everything else on that queue). But if we
are boosting a task from a low priority, why put it to the head of other
tasks of its new priority, when those tasks were just higher than this
task, and this task is now just an "equal".
-- Steve
> So Should the conditional be a reverse form (provided
> that less number means higher priority)? Please shed some light on me.
>
> Thanks,
> Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Question] sched/rt_mutex: re-enqueue_task on rt_mutex_setprio()
On Sat, 2012-07-07 at 14:44 +0900, Namhyung Kim wrote:
Hi,
I have a question on the code below:
void rt_mutex_setprio(struct task_struct *p, int prio)
{
...
if (on_rq)
enqueue_task(rq, p, oldprio prio ? ENQUEUE_HEAD : 0);
When enqueueing @p with new @prio, it seems put @p at the head of a
rq if appropriate. I guess it's the case of boosting @p with higher
priority, right?
Actually, no. We put @p at the head of the queue when unboosting. If a
task is going from a high priority into a lower priority, it is still
treated as important for that priority, and is put to the front of the
queue (it was just higher than everything else on that queue). But if we
are boosting a task from a low priority, why put it to the head of other
tasks of its new priority, when those tasks were just higher than this
task, and this task is now just an equal.
-- Steve
So Should the conditional be a reverse form (provided
that less number means higher priority)? Please shed some light on me.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
