Nick Piggin wrote: > Actually, I would still like to be able to deprecate deadline for > AS, because AS has a tunable that you can switch to turn off read > anticipation and revert to deadline behaviour (or very close to).
You mean antic_expire? I tried it, and it does have an enormous effect on performance. Smaller values do mimic deadline behavior in a way, as deadline has some strange behaviour on sync, so it's closer to noop, which is good for single user/proc access, while larger values are good for multi user/proc access. But I always have to set it to 0, or else it starves sync with others reading. I wonder if these tunables couldn't be autotuned by some form of history-based access pattern detection? > It would have been nice if CFQ were then a layer on top of AS that > implemented priorities (or vice versa). And then AS could be > deprecated and we'd be back to 1 primary scheduler. > > Well CFQ seems to be going in the right direction with that, however > some large users still find AS faster for some reason... AS is faster no-contest. CFQ has some deep block-io/queue problem that slows it down up to 25%. It's related to max_sectors_kb and read_ahead_kb , and I mentioned this to Jens before, and AS show this problem sometimes too, but with CFQ it's much more prevalent. Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
