Comment 418 for bug 131094

Hi AZ,
thanks for your feedback.

>> IMHO if something overloads your machine with disk I/O it has to stall it.
> This is a bit tricky, because overload means that the machine will be able not complete all task in the time given, i.e. tasks will accumulate until the resources are exhausted. Though, we usually do not have this situation on desktop machines.

Excuse me - I didn't want to phrase it too hard - it is surely ok to assume that a system stays responsive :-)
But when you add an background indexer like in the initial example you add some serious load.
The system might add a few other things and somewhen it is this overloaded.
Would you agree to modify your "Though, we usually do not have this situation on desktop machines." to "Though, we usually *should* not have this situation on desktop machines."?

Because that is the point where my suggestion of "throttling the few loads that cause these situations" kicks in.

> So this bug is mostly about having too big delays in applications using only a small bit of the available resources (like when switching back to a libreoffice window) when some other applications (like background file indexing) are asking for the remaining disk io resource capacities.

When I think of an overload case where e.g. a Process submits requests as fast as it can (especially with asynchronous I/O a process can quickly fill up hundreds of I/Os to the block device layer).
Now what should a process scheduler or I/O scheduler do?
1. handle them asap -> achieve good throughput, but might add some stalls to the system
2. throttle them -> improves responsiveness by avoiding overload, but this comes at certain prices
2a) if the process scheduler stalls it people start to ask "there is nothing else on the runqueue, why isn't it running? I want to get all I can from my HW".
2b) if the I/O scheduler stalls it people start to ask "hey my device could handle way more, why isn't it fully utilized with the request queue being filled" (remember all the "fun" people had with anticipatory scheduler)

Both 2a and 2b existed in various patches/tunings and almost every time the decision was that "the default" can not be to stall too much because there are different demands.

That was the reason why I personally didn't think about a cool new piece of code (which surely someone could write), but instead of a good mitigation of the most frequent cases with tools that are already there (like the cgroup io throttling I suggested)

>> Code improves to mitigate effects but can never be perfect for *ALL* users at once (especially in the default config)
>I do not agree.

Long story short - a default configuration has to be a tradeoff trying to make everyone happy but no one sad (hard job).

> Desktop responsiveness was achieved with older ubuntu versions on the given hw and is achieved with other operating systems (windows) on a broad range of hardware.

I'm coming from the server world, and there I/O throughput, I/O latency and even process latency and fairness clearly is superior compared to older releases as well as when compared well to other OSes.
But that doesn't negate your experience - it is just a different one.

> I believe desktop responsiveness is something sufficiently specific a cpu and io scheduler can be tuned to.

You are right that probably cpu and io scheduler could be tuned, but that gets to the point of the default having to be a trade-off between different user groups demands - so the default might be right just neither for you (wants more responsiveness) nor for me (wants more I/O).

> Using cgroups and alike might help, but should be configured by Ubuntu by default if necessary.

And here I totally agree, we could really think about isolating the most obvious hogs. Especially those that people "didn't realize" they had.
So if one runs a huge database or an I/O benchmark he willingly chose a heavy I/O workload.
But if a background indexer causes the same, users might quite often not even know about its existence.
That is what I wanted to achieve with "open a separate bug requesting configurable throttling for each component applicable like trackerd and so many other I/O heavy background tasks"

Within those bugs it could be discussed and rated "per application" if it makes sense to either isolate and throttle them by default or at least to provide an easy method to do so.

Another way could be something like different "user/tuning profiles" to distinguish the need for different defaults.
But I guess we should strive to give the best out of the box experience so isolating the most obvious hogs first would surely be a good idea.