[lkml]   [2011]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 'autogroup' sched code KILLING responsiveness
On Sun, 23 Jan 2011 at 02:50, Christian Kujau wrote:
> On Fri, 21 Jan 2011 at 10:20, Michael Witten wrote:
> > With that code in place, a resource-intensive activity (such as
> > compiling the Linux kernel) causes my computer to become
> > unresponsive for many seconds at a time; the entire screen
> > does not refresh, typed keys are dropped or are handled very
> > late, etc (even in Linux's plain virtual consoles).
> Unfortunately, I'd like to add a "me too". 2.6.38-rc1 behaves fine, but
> with CONFIG_SCHED_AUTOGROUP=y and doing I/O and CPU intensive work (git
> prune/git repack on a Linux git tree), system load goes up to ~13 and
> becomes unresponse for some time too. This even happens when I start the
> jobs with nice -n10.

"unresponsive for some time" turned out to be "system unusable, unless
rebooted". When I started the "git repack" with the autogroup feature
turned on, load would go to 4 very quickly (as compared to 1 or 2 w/o
autogroup), after a while (seconds, minutes) it would go to 10 or 14 and I
cannot use the system any more, after a while it goes back to 4 but then
it goes up again, the last load number I see is 11.56 and now the system
is stuck or so busy that I cannot login any more, not even locally. This
happened before with 2.6.38-rc1 & CONFIG_SCHED_AUTOGROUP=y, so it's quite
reproducible for me.


> Without CONFIG_SCHED_AUTOGROUP enabled and doing the same work,
> systemload goes up to 1 or maybe 2.
> I'm on UP as well (PowerPC G4), disabling CONFIG_SCHED_AUTOGROUP helps
> here too.
> Thanks,
> Christian.

BOFH excuse #356:

the daemons! the daemons! the terrible daemons!

 \ /
  Last update: 2011-01-23 12:23    [W:0.118 / U:2.948 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site