Disk priority dependend on nice level...

Disk priority dependend on nice level...

[Pavel Machek]

Hi!

I ported `subj` to 2.6.0-test2. I do not yet have idea if it works,
but it compiles ;-).
								Pavel

--- clean/drivers/block/deadline-iosched.c	2003-07-27 22:31:10.000000000 +0200
+++ linux/drivers/block/deadline-iosched.c	2003-08-07 01:26:47.000000000 +0200
@@ -17,6 +17,7 @@
 #include <linux/compiler.h>
 #include <linux/hash.h>
 #include <linux/rbtree.h>
+#include <linux/sched.h>
 
 /*
  * See Documentation/deadline-iosched.txt
@@ -106,6 +107,19 @@
 #define RQ_DATA(rq)	((struct deadline_rq *) (rq)->elevator_private)
 
 /*
+ * scale_deadline
+ */
+static int scale_deadline(int default_deadline)
+{
+	int prio = current->static_prio - MAX_RT_PRIO;
+	/* make priorities higher than nice -10 equal to nice -10 */
+	if (prio < 10)
+		prio = 10;
+	/* scale the deadline according to priority */
+	return default_deadline * prio/20;
+}
+
+/*
  * the back merge hash support functions
  */
 static inline void __deadline_del_drq_hash(struct deadline_rq *drq)
@@ -303,7 +317,7 @@
 	/*
 	 * set expire time (only used for reads) and add to fifo list
 	 */
-	drq->expires = jiffies + dd->fifo_expire[data_dir];
+	drq->expires = jiffies + scale_deadline(dd->fifo_expire[data_dir]);
 	list_add_tail(&drq->fifo, &dd->fifo_list[data_dir]);
 }
 
 
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Disk priority dependend on nice level...

[Pavel Machek]

Hi!

> I ported `subj` to 2.6.0-test2. I do not yet have idea if it works,
> but it compiles ;-).

It compiles, it event boots, but it does not seem to have much effect
:-(.

Test was like this:

bench:
#!/bin/bash
doit() {
    echo Unloaded system:
    time ./$1
    echo No nice:
    ./$1 loadonly &
    time ./$1
    killall $1
    killall bench_cat
    echo Nice -19:
    nice -n 19 ./$1 loadonly &
    time ./$1
    killall $1
    killall bench_cat
}

doit diskload


diskload:
#!/bin/bash
if [ "a$1" == aloadonly ]; then
	./bench_cat /usr/{bin,lib,lib/*}/* > /dev/null 2> /dev/null
	exit
fi
umount /suse
mount /suse
./bench_cat /suse/usr/bin/* > /dev/null 2> /dev/null


bench_cat is copy of /bin/cat.
									Pavel

> 
> --- clean/drivers/block/deadline-iosched.c	2003-07-27 22:31:10.000000000 +0200
> +++ linux/drivers/block/deadline-iosched.c	2003-08-07 01:26:47.000000000 +0200
> @@ -17,6 +17,7 @@
>  #include <linux/compiler.h>
>  #include <linux/hash.h>
>  #include <linux/rbtree.h>
> +#include <linux/sched.h>
>  
>  /*
>   * See Documentation/deadline-iosched.txt
> @@ -106,6 +107,19 @@
>  #define RQ_DATA(rq)	((struct deadline_rq *) (rq)->elevator_private)
>  
>  /*
> + * scale_deadline
> + */
> +static int scale_deadline(int default_deadline)
> +{
> +	int prio = current->static_prio - MAX_RT_PRIO;
> +	/* make priorities higher than nice -10 equal to nice -10 */
> +	if (prio < 10)
> +		prio = 10;
> +	/* scale the deadline according to priority */
> +	return default_deadline * prio/20;
> +}
> +
> +/*
>   * the back merge hash support functions
>   */
>  static inline void __deadline_del_drq_hash(struct deadline_rq *drq)
> @@ -303,7 +317,7 @@
>  	/*
>  	 * set expire time (only used for reads) and add to fifo list
>  	 */
> -	drq->expires = jiffies + dd->fifo_expire[data_dir];
> +	drq->expires = jiffies + scale_deadline(dd->fifo_expire[data_dir]);
>  	list_add_tail(&drq->fifo, &dd->fifo_list[data_dir]);
>  }
>  
>  

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Disk priority dependend on nice level...

[Jens Axboe]

On Thu, Aug 07 2003, Pavel Machek wrote:
> Hi!
> 
> > I ported `subj` to 2.6.0-test2. I do not yet have idea if it works,
> > but it compiles ;-).
> 
> It compiles, it event boots, but it does not seem to have much effect
> :-(.

Now that the queue reference counting is in the current bk tree, we are
that much closer to real modular io schedulers. I'll post the cfq with
priorities for that.

-- 
Jens Axboe

queue reference counting

[Nick Piggin]

Jens Axboe wrote:

>On Thu, Aug 07 2003, Pavel Machek wrote:
>
>>Hi!
>>
>>
>>>I ported `subj` to 2.6.0-test2. I do not yet have idea if it works,
>>>but it compiles ;-).
>>>
>>It compiles, it event boots, but it does not seem to have much effect
>>:-(.
>>
>
>Now that the queue reference counting is in the current bk tree, we are
>that much closer to real modular io schedulers. I'll post the cfq with
>priorities for that.
>

OK, the QUEUE_FLAG_DEAD. I assume that will be set in blk_cleanup_queue?
Then all remaining requests are flushed out of the queue?

This requires that a driver must be able to continue to process requests
during the call to blk_cleanup_queue, and that blk_cleanup_queue might
block, right? Is this acceptable, or should there be an earlier call to
set QUEUE_FLAG_DEAD and ensure queue is flushed?

Re: queue reference counting

[Jens Axboe]

On Thu, Aug 07 2003, Nick Piggin wrote:
> 
> 
> Jens Axboe wrote:
> 
> >On Thu, Aug 07 2003, Pavel Machek wrote:
> >
> >>Hi!
> >>
> >>
> >>>I ported `subj` to 2.6.0-test2. I do not yet have idea if it works,
> >>>but it compiles ;-).
> >>>
> >>It compiles, it event boots, but it does not seem to have much effect
> >>:-(.
> >>
> >
> >Now that the queue reference counting is in the current bk tree, we are
> >that much closer to real modular io schedulers. I'll post the cfq with
> >priorities for that.
> >
> 
> OK, the QUEUE_FLAG_DEAD. I assume that will be set in blk_cleanup_queue?
> Then all remaining requests are flushed out of the queue?
> 
> This requires that a driver must be able to continue to process requests
> during the call to blk_cleanup_queue, and that blk_cleanup_queue might
> block, right? Is this acceptable, or should there be an earlier call to
> set QUEUE_FLAG_DEAD and ensure queue is flushed?

The plan was to add blk_shutdown_queue() to do this. And then make sure
AS checks the dead flag and doesn't hold back any requests.

-- 
Jens Axboe

Re: queue reference counting

[Nick Piggin]

Jens Axboe wrote:

>On Thu, Aug 07 2003, Nick Piggin wrote:
>
>>
>>Jens Axboe wrote:
>>
>>
>>>On Thu, Aug 07 2003, Pavel Machek wrote:
>>>
>>>
>>>>Hi!
>>>>
>>>>
>>>>
>>>>>I ported `subj` to 2.6.0-test2. I do not yet have idea if it works,
>>>>>but it compiles ;-).
>>>>>
>>>>>
>>>>It compiles, it event boots, but it does not seem to have much effect
>>>>:-(.
>>>>
>>>>
>>>Now that the queue reference counting is in the current bk tree, we are
>>>that much closer to real modular io schedulers. I'll post the cfq with
>>>priorities for that.
>>>
>>>
>>OK, the QUEUE_FLAG_DEAD. I assume that will be set in blk_cleanup_queue?
>>Then all remaining requests are flushed out of the queue?
>>
>>This requires that a driver must be able to continue to process requests
>>during the call to blk_cleanup_queue, and that blk_cleanup_queue might
>>block, right? Is this acceptable, or should there be an earlier call to
>>set QUEUE_FLAG_DEAD and ensure queue is flushed?
>>
>
>The plan was to add blk_shutdown_queue() to do this. And then make sure
>AS checks the dead flag and doesn't hold back any requests.
>

Sounds sensible. Just ensuring I wasn't missing out on the fun.

Re: Disk priority dependend on nice level...

[Pavel Machek]

Hi!

> > > I ported `subj` to 2.6.0-test2. I do not yet have idea if it works,
> > > but it compiles ;-).
> > 
> > It compiles, it event boots, but it does not seem to have much effect
> > :-(.
> 
> Now that the queue reference counting is in the current bk tree, we are
> that much closer to real modular io schedulers. I'll post the cfq with
> priorities for that.

I'm looking forward to that. (If you have some patch I could test,
mail it my way).
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Disk priority dependend on nice level...

[Jens Axboe]

On Thu, Aug 07 2003, Pavel Machek wrote:
> Hi!
> 
> > > > I ported `subj` to 2.6.0-test2. I do not yet have idea if it works,
> > > > but it compiles ;-).
> > > 
> > > It compiles, it event boots, but it does not seem to have much effect
> > > :-(.
> > 
> > Now that the queue reference counting is in the current bk tree, we are
> > that much closer to real modular io schedulers. I'll post the cfq with
> > priorities for that.
> 
> I'm looking forward to that. (If you have some patch I could test,
> mail it my way).

What I have is still some kernel revisions old, plus it's using the
modular io scheduler interface. So I cannot easily post anything, you
will have to wait until after my vacation I'm afraid.

-- 
Jens Axboe

Re: Disk priority dependend on nice level...

[Jens Axboe]

On Thu, Aug 07 2003, Pavel Machek wrote:
> Hi!
> 
> I ported `subj` to 2.6.0-test2. I do not yet have idea if it works,
> but it compiles ;-).

This wont do much, you might as well forget it. Disk priorities is far
more work than you appear to think :)

-- 
Jens Axboe

Re: Disk priority dependend on nice level...

[Pavel Machek]

Hi!

> > I ported `subj` to 2.6.0-test2. I do not yet have idea if it works,
> > but it compiles ;-).
> 
> This wont do much, you might as well forget it. Disk priorities is far
> more work than you appear to think :)

This was not my patch, I only ported it.

I'm not heading for "perfect" disk priorities (not now :-), but having
something with at least measurable effect would be nice.

For a start "niced processes get starved during I/O" should do the
trick. (And it would help my lingvistics workloads).
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Disk priority dependend on nice level...

[Jens Axboe]

On Thu, Aug 07 2003, Pavel Machek wrote:
> Hi!
> 
> > > I ported `subj` to 2.6.0-test2. I do not yet have idea if it works,
> > > but it compiles ;-).
> > 
> > This wont do much, you might as well forget it. Disk priorities is far
> > more work than you appear to think :)
> 
> This was not my patch, I only ported it.
> 
> I'm not heading for "perfect" disk priorities (not now :-), but having
> something with at least measurable effect would be nice.
> 
> For a start "niced processes get starved during I/O" should do the
> trick. (And it would help my lingvistics workloads).

Well it just cannot work in any sort of useful way like this, I think
the patch is pretty useless...

-- 
Jens Axboe