[patch] cfq: ioprio inherit rt class

[patch] cfq: ioprio inherit rt class

[Con Kolivas]

Jens, ml

I was wondering if cfq io priorities should be explicitly set to the realtime 
class when no io priority is specified from realtime tasks as in the 
following patch? (rt_task() will need to be modified to suit the PI changes in
-mm)

---
Set cfq io priority class to realtime and scale the priority according to the
rt priority when no io priority is explicitly set in realtime tasks.

Signed-off-by: Con Kolivas <kernel@kolivas.org>

---
 block/cfq-iosched.c    |    4 ++--
 include/linux/ioprio.h |   12 +++++++++++-
 2 files changed, 13 insertions(+), 3 deletions(-)

Index: linux-2.6.17-rc5-ck2/block/cfq-iosched.c
===================================================================
--- linux-2.6.17-rc5-ck2.orig/block/cfq-iosched.c	2006-05-25 21:32:45.000000000 +1000
+++ linux-2.6.17-rc5-ck2/block/cfq-iosched.c	2006-05-25 23:55:22.000000000 +1000
@@ -1334,10 +1334,10 @@ static void cfq_init_prio_data(struct cf
 			printk(KERN_ERR "cfq: bad prio %x\n", ioprio_class);
 		case IOPRIO_CLASS_NONE:
 			/*
-			 * no prio set, place us in the middle of the BE classes
+			 * Select class and ioprio according to policy and nice
 			 */
+			cfqq->ioprio_class = task_policy_ioprio_class(tsk);
 			cfqq->ioprio = task_nice_ioprio(tsk);
-			cfqq->ioprio_class = IOPRIO_CLASS_BE;
 			break;
 		case IOPRIO_CLASS_RT:
 			cfqq->ioprio = task_ioprio(tsk);
Index: linux-2.6.17-rc5-ck2/include/linux/ioprio.h
===================================================================
--- linux-2.6.17-rc5-ck2.orig/include/linux/ioprio.h	2006-05-25 23:02:06.000000000 +1000
+++ linux-2.6.17-rc5-ck2/include/linux/ioprio.h	2006-05-25 23:55:22.000000000 +1000
@@ -22,7 +22,7 @@
  * class, the default for any process. IDLE is the idle scheduling class, it
  * is only served when no one else is using the disk.
  */
-enum {
+enum ioprio_class {
 	IOPRIO_CLASS_NONE,
 	IOPRIO_CLASS_RT,
 	IOPRIO_CLASS_BE,
@@ -51,8 +51,18 @@ static inline int task_ioprio(struct tas
 	return IOPRIO_PRIO_DATA(task->ioprio);
 }
 
+static inline enum ioprio_class
+	task_policy_ioprio_class(struct task_struct *task)
+{
+	if (rt_task(task))
+		return IOPRIO_CLASS_RT;
+	return IOPRIO_CLASS_BE;
+}
+
 static inline int task_nice_ioprio(struct task_struct *task)
 {
+	if (rt_task(task))
+		return (task->rt_priority * IOPRIO_BE_NR / MAX_RT_PRIO);
 	return (task_nice(task) + 20) / 5;
 }
 

-- 
-ck

Re: [patch] cfq: ioprio inherit rt class

[Con Kolivas]

On Saturday 27 May 2006 11:50, Con Kolivas wrote:
> Jens, ml
>
> I was wondering if cfq io priorities should be explicitly set to the
> realtime class when no io priority is specified from realtime tasks as in
> the following patch? (rt_task() will need to be modified to suit the PI
> changes in -mm)
>
> ---
> Set cfq io priority class to realtime and scale the priority according to
> the rt priority when no io priority is explicitly set in realtime tasks.

sorry, rather than this:
> +		return (task->rt_priority * IOPRIO_BE_NR / MAX_RT_PRIO);

it should be:
return ((MAX_RT_PRIO - task->rt_priority) * IOPRIO_BE_NR / MAX_RT_PRIO);

-- 
-ck

Re: [ck] [patch] cfq: ioprio inherit rt class

[Jens Axboe]

On Sat, May 27 2006, Con Kolivas wrote:
> Jens, ml
> 
> I was wondering if cfq io priorities should be explicitly set to the realtime 
> class when no io priority is specified from realtime tasks as in the 
> following patch? (rt_task() will need to be modified to suit the PI changes in
> -mm)

Not sure. RT io needs to be considered carefully, but I guess so does RT
CPU scheduling. For now I'd prefer to play it a little safer, and only
inheric the priority value and not the class.

-- 
Jens Axboe

Re: [patch] cfq: ioprio inherit rt class

[Con Kolivas]

On Saturday 03 June 2006 03:12, Jens Axboe wrote:
> On Sat, May 27 2006, Con Kolivas wrote:
> > Jens, ml
> >
> > I was wondering if cfq io priorities should be explicitly set to the
> > realtime class when no io priority is specified from realtime tasks as in
> > the following patch? (rt_task() will need to be modified to suit the PI
> > changes in -mm)
>
> Not sure. RT io needs to be considered carefully, but I guess so does RT
> CPU scheduling. For now I'd prefer to play it a little safer, and only
> inheric the priority value and not the class.

The problem I envisioned with that was that realtime tasks, if they don't 
specify an io priority (as most current code doesn't), would basically get io 
priority 4 and have the same proportion as any nice 0 SCHED_NORMAL task 
whereas -nice tasks automatically are getting better io priority. How about 
givent them normal class but best priority so they are at least getting the 
same as nice -20?

-- 
-ck

Re: [patch] cfq: ioprio inherit rt class

[Lee Revell]

On Sat, 2006-06-03 at 10:10 +1000, Con Kolivas wrote:
> On Saturday 03 June 2006 03:12, Jens Axboe wrote:
> > Not sure. RT io needs to be considered carefully, but I guess so does RT
> > CPU scheduling. For now I'd prefer to play it a little safer, and only
> > inheric the priority value and not the class.
> 
> The problem I envisioned with that was that realtime tasks, if they don't 
> specify an io priority (as most current code doesn't), would basically get io 
> priority 4 and have the same proportion as any nice 0 SCHED_NORMAL task 
> whereas -nice tasks automatically are getting better io priority. How about 
> givent them normal class but best priority so they are at least getting the 
> same as nice -20?
> 

Con,

Have you seen RT threads trying to disk IO 'in the wild' or is this a
theoretical concern?  I don't know of any such apps.

Lee

Re: [patch] cfq: ioprio inherit rt class

[Horst von Brand]

Lee Revell <rlrevell@joe-job.com> wrote:
> On Sat, 2006-06-03 at 10:10 +1000, Con Kolivas wrote:
> > On Saturday 03 June 2006 03:12, Jens Axboe wrote:
> > > Not sure. RT io needs to be considered carefully, but I guess so does RT
> > > CPU scheduling. For now I'd prefer to play it a little safer, and only
> > > inheric the priority value and not the class.

> > The problem I envisioned with that was that realtime tasks, if they
> > don't specify an io priority (as most current code doesn't), would
> > basically get io priority 4 and have the same proportion as any nice 0
> > SCHED_NORMAL task whereas -nice tasks automatically are getting better
> > io priority. How about givent them normal class but best priority so
> > they are at least getting the same as nice -20?

> Have you seen RT threads trying to disk IO 'in the wild'

I'd be surprised, to be sure.

>                                                          or is this a
> theoretical concern?  I don't know of any such apps.

Is it hard to do? If not, as this isn't forbidden as such, it makes sense
IMVHO.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [patch] cfq: ioprio inherit rt class

[Con Kolivas]

On Sunday 04 June 2006 03:40, Lee Revell wrote:
> On Sat, 2006-06-03 at 10:10 +1000, Con Kolivas wrote:
> > On Saturday 03 June 2006 03:12, Jens Axboe wrote:
> > > Not sure. RT io needs to be considered carefully, but I guess so does
> > > RT CPU scheduling. For now I'd prefer to play it a little safer, and
> > > only inheric the priority value and not the class.
> >
> > The problem I envisioned with that was that realtime tasks, if they don't
> > specify an io priority (as most current code doesn't), would basically
> > get io priority 4 and have the same proportion as any nice 0 SCHED_NORMAL
> > task whereas -nice tasks automatically are getting better io priority.
> > How about givent them normal class but best priority so they are at least
> > getting the same as nice -20?
>
> Con,
>
> Have you seen RT threads trying to disk IO 'in the wild' or is this a
> theoretical concern?  I don't know of any such apps.
>

Yeah, cd burning software comes to mind.

-- 
-ck