Messages in this thread | | | Date | Wed, 30 Mar 2011 14:34:46 -0400 | From | Vivek Goyal <> | Subject | Re: Why do we use cpu nice priority for ioprio? |
| |
On Wed, Mar 30, 2011 at 11:23:45AM -0700, Justin TerAvest wrote: > On Fri, Mar 25, 2011 at 12:48 AM, Jens Axboe <jaxboe@fusionio.com> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |