Skip to contentSkip to conversation

Disk priority dependend on nice level...

PATCH Pavel Machek 4 participants 11 messages Aug 6, 2003 – Aug 7, 2003 Block layer

lore
Share & tools
lore
#0 lore raw

Hi!

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

drivers/block/deadline-iosched.c +15 -1
@@ -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]);
 }
 
Signature · 2 lines
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
#1 lore raw

Hi!

Quoted 2 lines

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

Quoted 41 lines
drivers/block/deadline-iosched.c +15 -1
@@ -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]);
 }
 
Signature · 2 lines
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
#2 lore raw
Quoted 7 lines · Pavel Machek

Hi!

Quoted 2 lines

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.

Signature · 1 line
Jens Axboe
#3 lore raw

queue reference counting

Quoted 8 lines · Jens Axboe
Quoted 6 lines · Pavel Machek

Hi!

Quoted 3 lines

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

Quoted 8 lines
Quoted 3 lines

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?

#4 lore raw

Re: queue reference counting

Quoted 21 lines · Nick Piggin
Quoted 8 lines · Jens Axboe
Quoted 6 lines · Pavel Machek

Hi!

Quoted 3 lines

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

Quoted 8 lines
Quoted 3 lines

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.

Quoted 7 lines

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.

Signature · 1 line
Jens Axboe
#5 lore raw

Re: queue reference counting

Quoted 29 lines · Jens Axboe
Quoted 27 lines · Nick Piggin
Quoted 11 lines · Jens Axboe
Quoted 8 lines · Pavel Machek

Hi!

Quoted 4 lines

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

Quoted 9 lines
Quoted 4 lines

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?

Quoted 9 lines
Quoted 5 lines

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.

#6 lore raw
In reply to Jens Axboe

Hi!

Quoted 9 lines
Quoted 5 lines
Quoted 2 lines

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

Signature · 2 lines
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
#7 lore raw
Quoted 8 lines · Pavel Machek

Hi!

Quoted 6 lines
Quoted 5 lines
Quoted 2 lines

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 :-(.

Quoted 6 lines
Quoted 3 lines

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.

Signature · 1 line
Jens Axboe
#8 lore raw
In reply to Pavel Machek
Quoted 4 lines · 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 :)

Signature · 1 line
Jens Axboe
#9 lore raw

Hi!

Quoted 5 lines
Quoted 2 lines

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

Signature · 2 lines
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
#10 lore raw
Quoted 8 lines · Pavel Machek

Hi!

Quoted 5 lines
Quoted 2 lines

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 :)

Quoted 7 lines

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...

Signature · 1 line
Jens Axboe