Re: Degrading disk read performance under 2.2.16
On Mon, 14 Aug 2000, Jens Axboe wrote: I found that increasing the read_latency to match write_latency fixes the problems perfectly - thanks for the pointer! Ok good. Andrea, could we bump read latency in 2.2.17-pre? Yes. Increasing the read_latency and write_latency to 10,000,000 results in similar throughput, but catastrophic seek performance: Odd... I guess it was the tiotest "Seek" bug that I mentioned in the other email. to backup the values chosen. But the current defaults do impose performance problems, as they did in 2.4, so I think that up'ing read latency is a good idea. Agreed. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Degrading disk read performance under 2.2.16
On Mon, 14 Aug 2000, Corin Hartland-Swann wrote:
I have tried this out, and found that the default settings were:
elevator ID=232 read_latency=128 write_latency=8192 max_bomb_segments=4
(side note: Jens increased bomb segments to 32 in recent 2.2.17)
I think we can apply this patch on top of the recent 2.2.17:
--- 2.2.17pre11/include/linux/blkdev.h Wed Aug 2 19:33:35 2000
+++ /tmp/blkdev.h Mon Aug 14 17:21:14 2000
@@ -48,9 +48,9 @@
#define ELEVATOR_DEFAULTS \
((elevator_t) {\
- 128,/* read_latency */ \
- 8192, /* write_latency */ \
- 32, /* max_bomb_segments */ \
+ 5, /* read_latency */ \
+ 10, /* write_latency */ \
+ 128,/* max_bomb_segments */ \
0 /* queue_ID */ \
})
Corin could you test the _below_ patch on top of 2.2.16? (please don't
change to 2.2.17pre while doing the benchmarks because I don't want to add
other variables to the equation)
--- 2.2.16/include/linux/blkdev.h Thu Jun 22 00:07:54 2000
+++ /tmp/blkdev.h Mon Aug 14 17:21:14 2000
@@ -48,9 +48,9 @@
#define ELEVATOR_DEFAULTS \
((elevator_t) {\
- 128,/* read_latency */ \
- 8192, /* write_latency */ \
- 4, /* max_bomb_segments */ \
+ 5, /* read_latency */ \
+ 10, /* write_latency */ \
+ 128,/* max_bomb_segments */ \
0 /* queue_ID */ \
})
The rason read latency was so small is that it was avoiding completly
large writes to stall reads. But that was too much aggressive against
throughput and what people only cares is that one task can't be starved
for 49hours (or more or less depending on the speed of the disk) as it
could happen in real life with the 2.2.15 elevator.
The current 2.2.17pre code is also calculating the latency in function of
the position the request is placed in the queue. This logic can be turned
off as well as we giveup in making a background write not visible. (that's
not a big deal with the above settings, but it could save some minor CPU
cycle)
There's no way to conciliate the two worlds (at least without user
intervention). If we want to make a background write not visible, due the
nature of reads and/or of paging we must do an huge number of seeks at
high frequency. And doing that means screwing up benchmark numbers. And
everybody cares about benchmarks. So I just giveup with providing good
latency as default (you have to tune by hand to do that) but I only care
to avoid the 49hours starvation case :)), that was the real bugfix after
all.
Can anyone point me to any documentation on this elevator code? I was
wondering what exactly the different variables do...
I found that increasing the read_latency to match write_latency fixes the
problems perfectly - thanks for the pointer!
As a recap, here are the 2.2.15 (last known good) results:
== 2.2.15 ==
- -- --- - -- --
Dir Size BlkSz Thr# Read (CPU%) Write (CPU%) Seeks (CPU%)
- -- --- - -- --
/mnt/ 25640961 27.1371 10.3% 26.7979 23.0% 146.187 0.95%
/mnt/ 25640962 27.1219 10.7% 26.6606 23.2% 142.233 0.60%
/mnt/ 25640964 26.9915 10.6% 26.4289 22.9% 142.789 0.50%
/mnt/ 256409616 26.4320 10.5% 26.1310 23.0% 147.424 0.52%
/mnt/ 256409632 25.3407 10.1% 25.6822 22.7% 150.750 0.57%
Please apply the second patch in this email to 2.2.16 and show what the
tiotest produces.
Ah and btw, ignore completly the "Seeks" column, such part of benchark is
broken. I fixed it on my tree for my local benchmarks here, here's the
fix:
--- tiobench-0.3.1/tiotest.c.~1~Sun May 14 15:48:51 2000
+++ tiobench-0.3.1/tiotest.cMon Aug 14 17:27:19 2000
@@ -858,7 +858,7 @@
unsigned int seed;
struct timeval r;
- if(gettimeofday( r, NULL ) == 0)
+ if(0 gettimeofday( r, NULL ) == 0)
{
seed = r.tv_usec;
}
(note the above only means the "seek" column gets a sense on your local
machine without changing glibc, if you repalce the pseudo random number
generator in glibc between the runs of tiotest than the numbers can't be
compared anymore)
Also make sure to run such benchmark on a fresh filesystem always after a
mke2fs (What I usually do is to run mke2fs, reboot and run the benchmark
in single user mode).
Now, does anyone (Andrea in particular) know where the defaults are set? I
See the patch.
As an aside (sorry, I keep going off on
Re: raid-2.2.17-A0 cleanup for LVM
On Mon, 7 Aug 2000, Carlos Carvalho wrote: So can't this be fixed? Everything can be fixed, the fact is that I'm not sure if it worth, we'd better spend efforts in making 2.4.x more stable than overbackporting new stuff to 2.2.x... The fix precisely to allow raid5 on raid0 could be pretty localized if done in the wrong way though (with wrong way I mean not in the 2.4.x way). Andrea
Re: raid-2.2.17-A0 cleanup for LVM
On Thu, 3 Aug 2000, G.W. Wettstein wrote: On Aug 2, 7:12pm, Andrea Arcangeli wrote: } Subject: raid-2.2.17-A0 cleanup for LVM This patch cleanups the new raid code so that we have a chance that LVM on top of RAID will keep working. It's untested at the moment. ftp://ftp.*.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.17pre13/raid-2.2.17-A0/raid-lvm-cleanup-1 What are people using for LVM code on 2.2.1[67]? Grab 2.2.15aa1 or 2.2.17pre11aa2, they have completly reliable LVM (I also switch between it and 2.4.x stock without changing anything). It can be used for production. You can find the separate patches that compose that kernel in the ftp site as well. Andrea
raid-2.2.17-A0 cleanup for LVM
This patch cleanups the new raid code so that we have a chance that LVM on top of RAID will keep working. It's untested at the moment. ftp://ftp.*.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.17pre13/raid-2.2.17-A0/raid-lvm-cleanup-1 Andrea
Re: [patch] block device stacking support, raid-2.3.47-B6
On Wed, 23 Feb 2000, Ingo Molnar wrote: - renaming -make_request_fn() to -logical_volume_fn is both misleading and unnecessery. Note that with my proposal it was make_request_fn to be misleading because all the code run within the callback had anything to do with the make_request code. i've added the good bits (i hope i found all of them) from Andrea's patch as well: the end_io() fix in md.c, the -make_request() change returning IO errors, and avoiding an unnecessery get_queue() in the fast path. Ok. - device resolves recursion internally and returns 0 (future RAID0), returns 1 if recursion cannot be resolved internally. I don't think it worth to handle such case if it costs something for the other cases. I'll check and test the code on the LVM side soon. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: raid for kernel 2.2.11 used with 2.2.14 panics
[ Wednesday, January 5, 2000 ] Brian Kress wrote: I think Andrea Arcangeli has a fix for this. Search the lkml archives for something on set blocksize. It's an incremental patch over RAID 0.90. Yes, if you are using the new raid code with 2.2.14 you should apply also this below patch on the top of 2.2.14+raid: ftp://ftp.*.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.14pre11/set_blocksize-1-raid0145-19990824-2.2.11.gz Andrea
Re: 2.2.14aa1
On Wed, 5 Jan 2000, James Manning wrote: I noticed set_blocksize was left out... so was it included in 2.2.14 vanilla and there's a diff. source of the problem Yes it was included into 2.2.14. the linux-raid guy is having using the 2.2.11 patch? hmmm Yes that's the source of the problem. People using raid should apply the raid patch over 2.2.14 and then apply this incremental patch over 2.2.14+raid: ftp://ftp.*.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.14pre11/set_blocksize-1-raid0145-19990824-2.2.11.gz oSupport for 2048Gigabyte of RAM on alpha (stock 2.2.14 alpha limit is of 2Giga of RAM) (me) you can say 2TB, I think most ppl understand what TB is :) Yep :). Andrea
Re: Disk Corruption with ide hpt-366 controller software raid5
On Tue, 14 Sep 1999, Rogier Wolff wrote: If you're seeing THIS kind of errors, it SURE looks like a hardware issue. If the software is making errors, I'd expect a random byte Don't understimate the RAM. Some month ago reports like this got solved by replacing the only RAM in the system. Andrea
