lkml.org 
[lkml]   [2001]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [resent PATCH] Re: very slow parallel read performance
On Sun, Aug 26, 2001 at 10:48:05AM -0300, Rik van Riel <riel@conectiva.com.br> wrote:
> Margo Selzer wrote a nice paper on letting an elevator
> algorithm take care of request sorting. Only at the point
> where several thousand requests were queued and latency
> to get something from disk grew to about 30 seconds did
> a disk system relying on just an elevator get anything
> close to decent throughput.

But this is totally irrelevant. The elevator is the only thing left to do.
(and, as I said, rhe latency until data transfer starts is already about
16 seconds ;).

I believe I can get 5-6MB/s in the best case out of the system, and if the
elevator optimization coming from, say, 64 threads gives me 5.5 instead
of 5MB/s I would be very happy. Conversely, I could reduce the initial
latency by using smaller buffers if this optimization worked.

> This paper convinced me that doing just elevator sorting
> is never enough ;)

It must be enough, unfortunately ;) Ok, I could add user-limits or
somesuch, but I never believed in such a thing myself.

> One thing you could do, in recent -ac kernels, is make the
> maximum readahead size smaller by lowering the value in
> /proc/sys/vm/max-readahead

Yes, this indeed helps slightly (with the ac9 kernel I don't see the
massive thrashing going on with the linus' ones anyway). Now the only
thing left would be to be able to to that per access (even per disk would
help), as I, of course, rely on read-ahead for all other things going on
on that server ;)

It seems that I can in excess of 4MB/s (sometimes 5MB/s) when using large
bounce-buffers and disabling read-ahead completely under ac9. So something
with the kernel read-ahead *is* going wrong, as the default read-ahead
of 31 (pages? 124k) is very similar to my current read-buffer size of
128k. And enabling read-ahead and decreasing the user-space buffers gives
abysmal performance again.

>
> regards,
>
> Rik
> --
> IA64: a worthy successor to i860.
>
> http://www.surriel.com/ http://distro.conectiva.com/
>
> Send all your spam to aardvark@nl.linux.org (spam digging piggy)
>

--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@goof.com |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
-
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/

\
 
 \ /
  Last update: 2005-03-22 12:58    [W:0.117 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site