[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110330183446.GG1291@redhat.com>
Date: Wed, 30 Mar 2011 14:34:46 -0400
From: Vivek Goyal <vgoyal@...hat.com>
To: Justin TerAvest <teravest@...gle.com>
Cc: Jens Axboe <jaxboe@...ionio.com>,
lkml <linux-kernel@...r.kernel.org>,
Chad Talbott <ctalbott@...gle.com>
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@...ionio.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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists