Submitter : coreym Status : open
Assigned Engineer : nb Priority : 3
*Modified Date : 12/04/00 *Modified User : raa
*Modified User Domain : sgi.com *Description :
I ran rwtest on a xfs-linux filesystem on the machine permit:
rwtest 100000000:/mnt1/file_1 >/tmp/file_1.out 2>&1 &
This caused df, ls -l, fdisk, and top all to hang.
Permit is running Redhat 6.2 with a 2.4.0-test5 kernel
==========================
ADDITIONAL INFORMATION (ADD)
.....
==========================
ADDITIONAL INFORMATION (ADD)
From: "bob albers jr." <raa@xxxxxxx>
Date: Dec 04 2000 12:30:04PM
[pvnews version: 1.71]
==========================
> This is is a system hang problem that sounds fairly serious.
> However, it looks like it is only related to the xfs filesystem.
> I sent e-mail to the case owner (nb@sgi whoever that is) and
> offered help. If we can help with this I will try to get
> Sean on it.
Actually, I own it now since Neil passed XFS Linux management on to me.
There's been a potential fix generated for this problem. There also may be
some code tweaking that can be done to avoid this.
I've attached Steve Lord's e-mail on the subject.
Bob
>From owner-slinx-xfs@xxxxxxxxxxxxxxxxxxxx Tue Nov 21 04:14:08 2000
To: slinx-xfs@xxxxxxxxxxxx
Subject: I wonder if this is the elevator bug we have seen?
Date: Tue, 21 Nov 2000 04:06:51 -0600
From: Steve Lord <lord@xxxxxxx>
Anyone want to give Corey a kernel with this in it?
Steve
------- Forwarded Message
Date: Tue, 21 Nov 2000 17:38:44 +0900
From: kumon@xxxxxxxxxxxxxxxxxx
To: linux-kernel@xxxxxxxxxxxxxxx
cc: Dave Jones <davej@xxxxxxx>, Andrea Arcangeli <andrea@xxxxxxx>,
Jens Axboe <axboe@xxxxxxx>,
kumon@xxxxxxxxxxxxxxxxxx
Subject: [PATCH] livelock in elevator scheduling
The current elevator_linus() doesn't obey the true elevator
scheduling, and causes I/O livelock during frequent random write
traffics. In such environment I/O (read/write) transactions may be
delayed almost infinitely (more than 1 hour).
Problem:
Current elevator_linus() traverses the I/O requesting queue from the
tail to top. And when the current request has smaller sector number
than the request on the top of queue, it is always placed just after
the top.
This means, if requests in some sector range are continuously
generated, a request with larger sector number is always places at the
last and has no chance to go to the front. e.g. it is not scheduled.
This is not hypothetical but actually observed. Running a random
disk write benchmark can completely supress other disk I/O by this
reason.
The following patch fixes this problem. It still doesn't follow a
strict elevator scheduling, but it does much better. Additionally, it
may be better to add extra priority to reads than writes to obtain
better response, but this patch doesn't.
diff -ru linux-2.4.0-test11-pre2/drivers/block/elevator.c linux-2.4.0-test11-pr
e2-test5/drivers/block/elevator.c
- --- linux-2.4.0-test11-pre2/drivers/block/elevator.c Wed Aug 23 14:33:46 200
0
+++ linux-2.4.0-test11-pre2-test5/drivers/block/elevator.c Tue Nov 21 15:3
2:01 2000
@@ -47,6 +47,11 @@
break;
tmp->elevator_sequence--;
}
+ if (entry == head) {
+ tmp = blkdev_entry_to_request(entry);
+ if (IN_ORDER(req, tmp))
+ entry = real_head->prev;
+ }
list_add(&req->queue, entry);
}
To implement a complete elevator scheduling, preparing an alternate
waiting queue is better, I think.
- --
Computer Systems Laboratory, Fujitsu Labs.
kumon@xxxxxxxxxxxxxxxxxx
- -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
Please read the FAQ at http://www.tux.org/lkml/
------- End of Forwarded Message
|