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/
This archive was generated by hypermail 2b29 : Fri Aug 31 2001 - 21:00:20 EST