> > > 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.
>
> so the efefctive read-ahead is 2min(per-block-device, kernel-global)"? if
> yes, then this would be ideal for my case, as usage patterns are strictly
> seperated by disk in the machine, so I could get the best of all worlds.
Yes.
> > tree, otherwise changing the default MAX_READAHEAD requires a recompile.
>
> I like the proposed ideas of making it autotune ;) I think very large
> readaheads make a lot of sense under normal loads with modern harddisks,
> but not always.
Well, autotuning will require some r&d, plus a settling in period. In the
meantime it's quite safe and useful to use a user-set global as you showed,
and also will be helpful during the development of the automagic version.
> [...]
> Also, this whole thread was very fruitfull for that server:
>
> 929 (929) connections
> 4084385150 bytes written in the last 1044.23861896992 seconds
> (3911352.3 bytes/s)
>
> which is almost twice as fast as with my old setup/config. Thanks to all
> who analyzed it, sent patches and gave hints (thttpd gave about 700kb/s
> on the same setup, with only 250 connections, but admittedly only 4k
> read-requests).
To recap, you made these changes:
- Changed to -ac
- Set max-readahead through proc
Anything else? Did you change MAX_SECTORS?
> I believe that, with some tweaking (more memory dedicated to buffers), I
> could go to 4.5 and maybe 5mb/s, but certainly not much higher. And it's
> no longer thrashing. And linux does the job nicely ;)
Good, but should we rest on our laurels now?
-- 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/