Messages in this thread |  | | | From | Daniel Phillips <> | | Subject | Re: [resent PATCH] Re: very slow parallel read performance | | Date | Sun, 26 Aug 2001 19:29:43 +0200 |
| |
On August 26, 2001 04:49 am, pcg@goof.com ( Marc) (A.) (Lehmann ) wrote: > On Sun, Aug 26, 2001 at 03:38:34AM +0200, Daniel Phillips <phillips@bonn-fries.net> wrote: > > Let's test the idea that readahead is the problem. If it is, then disabling > > readahead should make the lowlevel disk throughput match the highlevel > > throughput. Marc, could you please try it with this patch: > > No, I rebooted the machine before your mail and sinc wehtis is a production > server.. ;) > > Anyway, I compiled and bootet into linux-2.4.8-ac9. I jused ac8 on my > desktop machines and was not pleased with absolute performance but, unlike > the linus' series, I can listen to mp3's while working which was the > killer feature for me ;)
Yes, this probably points at a bug in linus's tree. This needs more digging. You're streaming the mp3's over the net or from your disk?
> anyway, AFAIU, one can tune raedahead dynamically under the ac9 series by > changing: > > isldoom:/proc/sys/vm# cat max-readahead > 31 > > If this is equivalent to your patch, then fine.
My patch would be equivalent to:
echo 0 >/proc/sys/vm/max-readahead
This was just to see if that makes the highlevel throughput match the lowlevel throughput, eliminating one variable from the equation. In -ac you have a much more convenient way of doing that.
> if not I will test it at a later time. Now, a question: how does the > per-block-device read-ahead fit into this picture? Is it being ignored? I > fiddled with it (under 2.4.8pre4) but couldn't see any difference.
It should not be being ignored. This needs to be looked into. In any event, the max-readahead proc setting is clearly good and needs to be in Linus's tree, otherwise changing the default MAX_READAHEAD requires a recompile. Worse, there is no way at all to specify the kernel's max-readahead for scsi disks - regardless of the fact that scsi disks do their own readahead, the kernel will do its own as well, with no way for the user to turn it off.
> [...] > Now the interesting part. setting read-ahead to 31 again, I increased the > number of reader threads from one to 64 and got 3.8MB (@450 connections, I > had to restart the server). > > So the ac9 kernel seems to work much better (than the linus' series), > although the number of connections was below the critical limit. I'll > check this when I get higher loads again.
The reason for that is still unclear. I realize you're testing this under live load (you're a brave man) but let's try a bringing the -ac max-readahead patch across and try it in 2.4.9.
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |