I have made the batch_expire timeouts smaller at double the non anticipatory
case - that seems to give comparable contest results - but it will still be a
loss in some situations.



 block/deadline-iosched.c |   16 +++++++---------
 1 files changed, 7 insertions(+), 9 deletions(-)

diff -puN drivers/block/deadline-iosched.c~ant-sched-12feb drivers/block/deadline-iosched.c
--- 25/drivers/block/deadline-iosched.c~ant-sched-12feb	2003-02-12 23:09:41.000000000 -0800
+++ 25-akpm/drivers/block/deadline-iosched.c	2003-02-12 23:09:41.000000000 -0800
@@ -56,18 +56,18 @@ static int write_expire = 5 * HZ;
  * read_batch_expire describes how long we will allow a stream of reads to
  * persist before looking to see whether it is time to switch over to writes.
  */
-static int read_batch_expire = HZ / 4;
+static int read_batch_expire = HZ / 10;
 
 /*
  * write_batch_expire describes how long we will allow a stream of writes to
  * persist before looking to see whether it is time to switch over to reads.
  */
-static int write_batch_expire = HZ / 10;
+static int write_batch_expire = HZ / 20;
 
 /*
  * max time we may wait to anticipate a read
  */
-static int antic_expire = HZ / 50;
+static int antic_expire = HZ / 100;
 
 static const int deadline_hash_shift = 10;
 #define DL_HASH_BLOCK(sec)	((sec) >> 3)
@@ -650,19 +650,17 @@ deadline_close_req(struct deadline_data 
 	
 	sector_t delta;	/* acceptable close offset (in sectors) */
 
-	if (dd->antic_status == ANTIC_OFF || delay <= 3)
-		delta = 16;
-	else if (delay <= 10)
-		delta = 64 << ((delay - 3)*2);
+	if (dd->antic_status == ANTIC_OFF || delay <= 2)
+		delta = 64;
 	else if (delay <= dd->antic_expire / 2)
-		delta = 1024 * 1024;
+		delta = 64 << ((delay - 2)*2);
 	else
 		return 1;
 
 	return (last <= next) && (next <= last + delta);
 }
 
-#define MAXBACK (256 * 1024)
+#define MAXBACK (512 * 1024)
 
 static struct deadline_rq *
 deadline_choose_req(struct deadline_data *dd,

_