It's not clear why the cpu nice value should be mapped to the ioprio
for a task when none is picked.
Internally, at cfq_init_prio_data(), we just set:
ioprio = IOPRIO_NORM;
ioprio_class = IOPRIO_CLASS_BE;
if ioprio_class is IOPRIO_CLASS_NONE.
The problem is that today, SCHED_RR and SCHED_FIFO threads
automatically get bumped up to RT class. This all happens behind the
curtains and the io_class of the thread is still shown as NONE with
sys_ioprio_get(). What's the motivation behind this promotion of
ioprio class?
I'd be happy to send a patch to change the behavior, but I'm curious
why the code promotes based on task nice values today.
Thanks!
On 2011-03-25 03:38, Justin TerAvest wrote:
> It's not clear why the cpu nice value should be mapped to the ioprio
> for a task when none is picked.
>
> Internally, at cfq_init_prio_data(), we just set:
> ioprio = IOPRIO_NORM;
> ioprio_class = IOPRIO_CLASS_BE;
> if ioprio_class is IOPRIO_CLASS_NONE.
>
>
> The problem is that today, SCHED_RR and SCHED_FIFO threads
> automatically get bumped up to RT class. This all happens behind the
> curtains and the io_class of the thread is still shown as NONE with
> sys_ioprio_get(). What's the motivation behind this promotion of
> ioprio class?
It was decided back in the day when io priorities were introduced. I
still think it's a good idea. You could argue that auto-bumping up to
IOPRIO_CLASS_RT is a bit heavy handed. But is it really that different
from the CPU scheduling?
So, from memory, the difference between RR and FIFO on the CPU
scheduling side is that one of them will relingiush the CPU for a brief
period once in a while. Correct? That does not happen for
IOPRIO_CLASS_RT. So at least from that perspective, it's not a complete
match and might be a cause for concern.
--
Jens Axboe
On Fri, Mar 25, 2011 at 12:48 AM, Jens Axboe <[email protected]> wrote:
> On 2011-03-25 03:38, Justin TerAvest wrote:
>> It's not clear why the cpu nice value should be mapped to the ioprio
>> for a task when none is picked.
>>
>> Internally, at cfq_init_prio_data(), we just set:
>> ? ? ? ? ? ? ? ioprio = IOPRIO_NORM;
>> ? ? ? ? ? ? ? ioprio_class = IOPRIO_CLASS_BE;
>> if ioprio_class is IOPRIO_CLASS_NONE.
>>
>>
>> The problem is that ?today, SCHED_RR and SCHED_FIFO threads
>> automatically get bumped up to RT class. This all happens behind the
>> curtains and the io_class of the thread is still shown as NONE with
>> sys_ioprio_get(). What's the motivation behind this promotion of
>> ioprio class?
>
> It was decided back in the day when io priorities were introduced. I
> still think it's a good idea.
This is the part I'm especially curious about. If we're managing the
resources separately,
why should be be adjusting io_class based on the nice value?
> You could argue that auto-bumping up to
> IOPRIO_CLASS_RT is a bit heavy handed. But is it really that different
> from the CPU scheduling?
But why do auto bumping at all? Is this for convenience, so users only
have to nice their tasks?
>
> So, from memory, the difference between RR and FIFO on the CPU
> scheduling side is that one of them will relingiush the CPU for a brief
> period once in a while. Correct? That does not happen for
> IOPRIO_CLASS_RT. So at least from that perspective, it's not a complete
> match and might be a cause for concern.
>
> --
> Jens Axboe
>
>
On Wed, Mar 30, 2011 at 11:23:45AM -0700, Justin TerAvest wrote:
> On Fri, Mar 25, 2011 at 12:48 AM, Jens Axboe <[email protected]> wrote:
> > On 2011-03-25 03:38, Justin TerAvest wrote:
> >> It's not clear why the cpu nice value should be mapped to the ioprio
> >> for a task when none is picked.
> >>
> >> Internally, at cfq_init_prio_data(), we just set:
> >> ? ? ? ? ? ? ? ioprio = IOPRIO_NORM;
> >> ? ? ? ? ? ? ? ioprio_class = IOPRIO_CLASS_BE;
> >> if ioprio_class is IOPRIO_CLASS_NONE.
> >>
> >>
> >> The problem is that ?today, SCHED_RR and SCHED_FIFO threads
> >> automatically get bumped up to RT class. This all happens behind the
> >> curtains and the io_class of the thread is still shown as NONE with
> >> sys_ioprio_get(). What's the motivation behind this promotion of
> >> ioprio class?
> >
> > It was decided back in the day when io priorities were introduced. I
> > still think it's a good idea.
>
> This is the part I'm especially curious about. If we're managing the
> resources separately,
> why should be be adjusting io_class based on the nice value?
What's wrong with taking a hint about ioclass and ioprio from cpu
scheduling class and nice value?
I think in general if some task is important from cpu perspective then
most likely it is important from IO perspective too. And if user thinks
otherwise, then one can explicitly set ioclass and ioprio of the task.
So this makes sense to me.
Thanks
Vivek
On Wed, Mar 30, 2011 at 11:34 AM, Vivek Goyal <[email protected]> wrote:
> On Wed, Mar 30, 2011 at 11:23:45AM -0700, Justin TerAvest wrote:
>> On Fri, Mar 25, 2011 at 12:48 AM, Jens Axboe <[email protected]> wrote:
>> > On 2011-03-25 03:38, Justin TerAvest wrote:
>> >> It's not clear why the cpu nice value should be mapped to the ioprio
>> >> for a task when none is picked.
>> >>
>> >> Internally, at cfq_init_prio_data(), we just set:
>> >> ? ? ? ? ? ? ? ioprio = IOPRIO_NORM;
>> >> ? ? ? ? ? ? ? ioprio_class = IOPRIO_CLASS_BE;
>> >> if ioprio_class is IOPRIO_CLASS_NONE.
>> >>
>> >>
>> >> The problem is that ?today, SCHED_RR and SCHED_FIFO threads
>> >> automatically get bumped up to RT class. This all happens behind the
>> >> curtains and the io_class of the thread is still shown as NONE with
>> >> sys_ioprio_get(). What's the motivation behind this promotion of
>> >> ioprio class?
>> >
>> > It was decided back in the day when io priorities were introduced. I
>> > still think it's a good idea.
>>
>> This is the part I'm especially curious about. If we're managing the
>> resources separately,
>> why should be be adjusting io_class based on the nice value?
>
> What's wrong with taking a hint about ioclass and ioprio from cpu
> scheduling class and nice value?
I guess it's fine. I was just curious how strongly everyone felt about
the way it works today. It sounds like we expect nice values and io
scheduling classes to be closely matched.
Thanks,
Justin
>
> I think in general if some task is important from cpu perspective then
> most likely it is important from IO perspective too. And if user thinks
> otherwise, then one can explicitly set ioclass and ioprio of the task.
>
> So this makes sense to me.
>
> Thanks
> Vivek
>