Ergo, i think pluggable designs for something as critical and as central as IO scheduling has its clear downsides as it created two mediocre schedulers:I rarely disagree with you, and more rarely feel like arguing a point in public, but you are basing your whole opinion on the premise that it is possible to have one io scheduler which handles all cases. And that seems obviously wrong, because you address different types of activity with tuning or adapting, in some cases you need a whole different approach, and you need to lock in that approach even if some metric says something else would be better for the "better" seen by the developer rather than the user.
- CFQ with all the modern features but performance problems on certain workloads
- Anticipatory with legacy features only but works (much!) better on some workloads.
... instead of giving us just a single well-working CFQ scheduler.
This, IMHO, in its current form, seems to trump the upsides of IO schedulers.
So i do think that late during development (i.e. now), _years_ down the line, we should make it gradually harder for people to use AS.
What do you think?I think that by trying to create "one size fits all" you will hit a significant number of cases where it really doesn't fit well and you have so many tuning features both automatic and manual that you wind up with code which is big, inefficient, confusing to tune, hard to maintain, and generally not optimal for any one thing.