The Linux desktop is about to get a LOT faster

[Samuel Thurston]

Hi,

On Sun, Nov 21, 2010 at 8:59 AM, John McCabe-Dansted <gmatht at gmail.com> wrote:
> As Lennart points out, running "make -j64" on a end-users desktop really
> isn't that common. [1] However, I have come across a similar case. Chome
> tends to have one process per tab. When those 30 odd processes start doing
> heavy IO simultaneously, my desktop can become so slow that it can take 15
> minutes just to kill enough processes to make my desktop responsive again.

In my understanding, having looked at the patch code as well as
lennart's solution, and read some of the surrounding LKML discussion,
the raw number of processes isn't as relevant to the benefit- however
of course the make -j# is selected relative to the number of cores (or
concurrent threads in the case of intel HT) a machine supports.  a
-j64 would only be run by someone with a 8-core HT processor since the
recommended dosage is 4 threads per cpu, IIRC.  Not a "typical"
desktop setup at this time.

>
> Unfortunately this patch only considers CPU, so I don't think it would help
> much here. I patched the kernel so I could use blkio cgroups, but have been
> unable to demonstrate that they have any affect what-so-ever, presumably I
> am missing something. However, it does seem that better management of IO is
> important, so someone familiar with cgroups may want to take a look.

The key with the current patch under discussion is that the cgroups
are organized per-tty so that all of those high-load make threads are
"priority grouped" as one, subject to more rapid interrupt by other
threads such as those governing UI clicking and repainting, and video
playback, because they have been launched from a single terminal.

Because of the way that chrome manages its threads (not from a tty)
tty cgroups won't help with latency in this case. I suspect that
unless your system is very low ram and forcing a lot of disk swapping,
blkio cgroups won't help either for similar reasons.

HOWEVER.  You could try launching chrome from a terminal with the tty
cgroups enabled through lennart's .bashrc solution,  and then have a
look at the /sys/fs/cgroup/cpu/user directory to see if/how the
threads are being grouped. additionally you might try two separate
chrome instances from two separate terminals with each having several
tabs and again compare the grouping.

you may, through experimentation, find a "magic number" of tabs you
can have within a single grouping to benefit desktop interactivity.