Messages in this thread |  | | | Date | Sun, 26 Aug 2001 16:55:17 +0200 | | From | < ( Marc) (A.) (Lehmann )> | | Subject | Re: [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/
|  |