Messages in this thread | | | Date | Mon, 10 Feb 2003 06:10:08 +0100 | From | Jakob Oestergaard <> | Subject | Re: stochastic fair queueing in the elevator [Re: [BENCHMARK] 2.4.20-ck3 / aa / rmap with contest] |
| |
On Mon, Feb 10, 2003 at 03:58:26PM +1100, Nick Piggin wrote: ... > >If we assume they are synchronous, that would be rather unfair > >especially on multi-user systems - and the 90% accuracy that Rik > >suggested would seem exaggerated to say the least (accuracy would be > >more like 10% on a good day). > > > Remember that readahead gets scaled down quickly if it isn't > getting hits. It is also likely to be sequential and in the > track buffer, so it is a small cost.
I buy the sequential-argument - very good point.
Thanks,
> Huge readahead is a problem however anticipatory scheduling > will hopefully allow good throughput for multiple read streams > without requiring much readahead.
I'm curious as to how these things will interact in the NFS server<->client situation :)
Time will show, I guess.
Random data-point (not meant as a rant - I'm happy for all I got ;)
In stock 2.4.20 the interaction is horrible - whatever was done there is not optimal. A 'tar xf' on the client will neither load the network nor the server - it seems to be network latency bound (readahead not doing it's job - changing min-readahead and max-readahead on the client doesn't seem to make a difference). However, my desktop (running on the client) can hang for 10 seconds straight every half hour or so, when the nightly backup runs on the server (local disk reads streaming at around 2 MB/sec from an array capable of at least 40 MB/sec).
-- ................................................................ : jakob@unthought.net : And I see the elder races, : :.........................: putrid forms of man : : Jakob Østergaard : See him rise and claim the earth, : : OZ9ABN : his downfall is at hand. : :.........................:............{Konkhra}...............: - 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/
| |