kernel-packages team mailing list archive

[ChristianEhrhardt <131094@xxxxxxxxxxxxxxxxxx>]

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.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/131094

Title:
  Heavy Disk I/O harms desktop responsiveness

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  Binary package hint: linux-source-2.6.22

  When compared with 2.6.15 in feisty, heavy disk I/O causes increased
  iowait times and affects desktop responsiveness in 2.6.22

  this appears to be a regression from 2.6.15 where iowait is much lower
  and desktop responsiveness is unaffected with the same I/O load

  Easy to reproduce with tracker - index the same set of files with
  2.6.15 kernel and 2.6.22 kernel and the difference in desktop
  responsiveness is massive

  I have not confirmed if a non-tracker process which does heavy disk
  i/o (especially writing) replicates this yet - will do further
  investigation soon

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/131094/+subscriptions