2.[45] fixes for design locking bug in wait_on_page/wait_on_buffer/get_request_wait
Hi Andrea,
I've applied your patch to 2.4.19 final and 2.4.20 final and those "pausings" still exists when I do a full kernel tree copy with "cp -a linux-2.4.19 linux-2.4.20". When I am in a screen session and try to do a Ctrl-A-C to create a new screen session it comes up within 3-5 seconds ... If I want to switch to another session with Ctrl-A-N it sometimes happens fast and sometimes within 3-5 seconds ... I've put above in a "while true; do ...; done" loop. There is nothing else running or eating CPU and also nothing else eating i/o. This does not happen with virgin 2.4.18.
This is with a Celeron Tualatin 1300MHz, i815 chipset, 512MB RAM, UDMA100 HDD, DMA enabled.
/dev/hda:
multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 8 (on)
geometry = 7299/255/63, sectors = 117266688, start = 0
Model=MAXTOR 6L060J3, FwRev=A93.0500, SerialNo=663219752652 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs } RawCHS=16383/16/63, TrkSize=32256, SectSize=21298, ECCbytes=4 BuffType=DualPortCache, BuffSize=1819kB, MaxMultSect=16, MultSect=16 CurCHS=4047/16/255, CurSects=16511760, LBA=yes, LBAsects=117266688 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 udma6 AdvancedPM=no WriteCache=enabled
Drive conforms to: ATA/ATAPI-5 T13 1321D revision 1: 1 2 3 4 5
Does also appear if unmaskirq is set to 1.
ciao, Marc
Quoted 10 lines · Marc-Christian Petersen
Hi Andrea,
I've applied your patch to 2.4.19 final and 2.4.20 final and those "pausings" still exists when I do a full kernel tree copy with "cp -a linux-2.4.19 linux-2.4.20". When I am in a screen session and try to do a Ctrl-A-C to create a new screen session it comes up within 3-5 seconds ... If I want to switch to another session with Ctrl-A-N it sometimes happens fast and sometimes within 3-5 seconds ... I've put above in a "while true; do ...; done" loop. There is nothing else running or eating CPU and also nothing else eating i/o. This does not happen with virgin 2.4.18.
Your pausing problem have little to do with the pausing fix, the problem for you is the read latency, you're not triggering the race condition fixed by the pausing fix so it can't make differences. One of the foundamental obstacles to the read latency is the size of the I/O queue, factor that is workarounded by the read-latency patch that basically bypasses the size of the queue hiding the problem and in turn can't fix the write latency with O_SYNC and the read latency during true read aio etc...
Andrea
On Saturday 16 November 2002 17:59, Andrea Arcangeli wrote:
Hi Andrea,
Quoted 8 lines
Your pausing problem have little to do with the pausing fix, the problem for you is the read latency, you're not triggering the race condition fixed by the pausing fix so it can't make differences. One of the foundamental obstacles to the read latency is the size of the I/O queue, factor that is workarounded by the read-latency patch that basically bypasses the size of the queue hiding the problem and in turn can't fix the write latency with
O_SYNCand the read latency during true read aio etc...
ok, after some further tests, I think this is _somewhat_ FS dependent. I tried this with ext2, ext3 (no difference there) and also with ReiserFS and what must I say, those "Pausings" caused be the write latency doing it with ReiserFS are alot less than with ext2|ext3 but are still occuring.
There must went in something bullshitty into 2.4.19/2.4.20 that causes those ugly things because 2.4.18 does not have that problem. This is still why I don't use any kernels >2.4.18.
After changing elevator things like this:
root@codeman:[/] # elvtune /dev/hda
/dev/hda elevator ID 0
read_latency: 2048
write_latency: 1024
max_bomb_segments: 0those "pausings" are less worse than before but are still there.
NOTE: Write latency is lower than read latency (it's not a typo :)
ciao, Marc
Quoted 25 lines · Marc-Christian Petersen
On Saturday 16 November 2002 17:59, Andrea Arcangeli wrote:
Hi Andrea,
Quoted 8 lines
Your pausing problem have little to do with the pausing fix, the problem for you is the read latency, you're not triggering the race condition fixed by the pausing fix so it can't make differences. One of the foundamental obstacles to the read latency is the size of the I/O queue, factor that is workarounded by the read-latency patch that basically bypasses the size of the queue hiding the problem and in turn can't fix the write latency with
O_SYNCand the read latency during true read aio etc...ok, after some further tests, I think this is _somewhat_ FS dependent. I tried this with ext2, ext3 (no difference there) and also with ReiserFS and what must I say, those "Pausings" caused be the write latency doing it with ReiserFS are alot less than with ext2|ext3 but are still occuring.
There must went in something bullshitty into 2.4.19/2.4.20 that causes those ugly things because 2.4.18 does not have that problem. This is still why I don't use any kernels >2.4.18.
After changing elevator things like this:
root@codeman:[/] # elvtune
/dev/hda
Quoted 7 lines
/dev/hda elevator ID 0 read_latency: 2048 write_latency: 1024 max_bomb_segments: 0those "pausings" are less worse than before but are still there.
NOTE: Write latency is lower than read latency (it's not a typo :)
you may want to try with this setting that helps with very slow devices:
echo 2 500 0 0 500 3000 3 1 0 > /proc/sys/vm/bdflush
or also with my current default tuned for high performance:
echo 50 500 0 0 500 3000 60 20 > /proc/sys/vm/bdflush
you may have too many dirty buffers around and you end running at disk speed at every memory allocation, the first setting will decrease the amount of dirty buffers dramatically, if you still have significant slowdown with the first setting above, it's most probably only the usual elevator issue.
Andrea
On Saturday 16 November 2002 18:32, Andrea Arcangeli wrote:
Hi Andrea,
Quoted 5 lines
you may want to try with this setting that helps with very slow devices:
echo 2 500 0 0 500 3000 3 1 0 > /proc/sys/vm/bdflushor also with my current default tuned for high performance:
echo 50 500 0 0 500 3000 60 20 > /proc/sys/vm/bdflush
I've tested both without any changes, "pausings" are still there.
Quoted 5 lines
you may have too many dirty buffers around and you end running at disk speed at every memory allocation, the first setting will decrease the amount of dirty buffers dramatically, if you still have significant slowdown with the first setting above, it's most probably only the usual elevator issue.
Seems so.
So I have to use 2.4.18 until there is a real proper fix for that.
ciao, Marc
Quoted 11 lines · Marc-Christian Petersen
On Saturday 16 November 2002 18:32, Andrea Arcangeli wrote:
Hi Andrea,
Quoted 5 lines
you may want to try with this setting that helps with very slow devices:
echo 2 500 0 0 500 3000 3 1 0 > /proc/sys/vm/bdflushor also with my current default tuned for high performance:
echo 50 500 0 0 500 3000 60 20 > /proc/sys/vm/bdflushI've tested both without any changes, "pausings" are still there.
Quoted 8 lines
Quoted 5 lines
you may have too many dirty buffers around and you end running at disk speed at every memory allocation, the first setting will decrease the amount of dirty buffers dramatically, if you still have significant slowdown with the first setting above, it's most probably only the usual elevator issue.
Seems so.
So I have to use 2.4.18 until there is a real proper fix for that.
just to make a quick test, can you try an hack like this combined with a setting of elvtune -r 128 -w 256 on top of 2.4.20rc1?
drivers/block/ll_rw_blk.c renamed from drivers/block/ll_rw_blk.c.~1~ +1 -1
@@ -432,7 +432,7 @@ static void blk_init_free_list(request_qsi_meminfo (&si); megs = si.totalram >> (20 -PAGE_SHIFT ); - nr_requests =128 ; + nr_requests =16 ;if (megs <32 ) nr_requests /=2 ;blk_grow_request_list (q, nr_requests);
Andrea