public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Galbraith <efault@gmx.de>
To: Michael Witten <mfwitten@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 'autogroup' sched code KILLING responsiveness
Date: Fri, 21 Jan 2011 23:27:50 +0100	[thread overview]
Message-ID: <1295648870.23779.15.camel@marge.simson.net> (raw)
In-Reply-To: <4d39ce58.cc7e0e0a.5448.59e4@mx.google.com>

On Fri, 2011-01-21 at 10:20 -0800, Michael Witten wrote:
> Bisecting shows that this commit:
> 
>   5091faa449ee0b7d73bc296a93bca9540fc51d0a
>   sched: Add 'autogroup' scheduling feature: automated per session task groups
>   Date:   Tue Nov 30 14:18:03 2010 +0100
> 
> is the reason that my computer has become unusable.
> 
> 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).

That's not what I'm experiencing with a UP kernel...

marge:~> time perf stat -a sh -c 'true'

 Performance counter stats for 'sh -c true':

             49580 cache-misses             #      5.170 M/sec  (scaled from 37.28%)
            336112 cache-references         #     35.048 M/sec  (scaled from 78.81%)
            185857 branch-misses            #     21.019 %      (scaled from 62.83%)
            884249 branches                 #     92.204 M/sec  (scaled from 21.25%)
          12672552 instructions             #      0.553 IPC    (scaled from 58.38%)
          22896301 cycles                   #   2387.490 M/sec  (scaled from 58.38%)
               410 page-faults              #      0.043 M/sec
                 0 CPU-migrations           #      0.000 M/sec
                13 context-switches         #      0.001 M/sec
          9.590115 task-clock-msecs         #      1.005 CPUs 

        0.009540836  seconds time elapsed


real    0m0.020s
user    0m0.000s
sys     0m0.000s
marge:~>

It took 20 ms to do the above and get it to my screen while the below
was running (among others).  I've got a make -j 100 running as I write
this, and don't even notice that it's running.

Can you provide some information such as hardware description,
configuration, and perhaps measurements demonstrating the problem?

top - 22:34:38 up 33 min, 22 users,  load average: 104.07, 101.73, 78.13
Tasks: 675 total, 101 running, 574 sleeping,   0 stopped,   0 zombie
Cpu(s): 95.2%us,  4.8%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  P COMMAND                                                              
 6770 root      20   0  401m  79m  29m R 46.9  1.0   3:22.66 0 mplayer                                                              
 6100 root      20   0  449m  94m  18m S  2.9  1.2   1:33.82 0 Xorg                                                                 
 7486 root      20   0  374m  46m  17m S  2.9  0.6   0:54.02 0 konsole                                                              
 7752 root      20   0  104m  66m 8072 R  1.0  0.8   0:01.76 0 cc1                                                                  
 9796 root      20   0 89764  49m 8028 R  1.0  0.6   0:01.21 0 cc1                                                                  
 9928 root      20   0 98916  59m 8164 R  1.0  0.7   0:01.18 0 cc1                                                                  
10321 root      20   0 88788  49m 8116 R  1.0  0.6   0:01.06 0 cc1                                                                  
10619 root      20   0 89736  50m 8068 R  1.0  0.6   0:01.00 0 cc1                                                                  
11356 root      20   0 19764 8152 2300 S  1.0  0.1   0:00.01 0 as                                                                   
11597 root      20   0 97212  56m 7924 R  1.0  0.7   0:00.65 0 cc1                                                                  
12203 root      20   0 79332  40m 7588 R  1.0  0.5   0:00.48 0 cc1                                                                  
12209 root      20   0 80760  40m 7536 R  1.0  0.5   0:00.47 0 cc1                                                                  
12247 root      20   0 85252  46m 7752 R  1.0  0.6   0:00.46 0 cc1                                                                  
12510 root      20   0 82192  40m 5184 R  1.0  0.5   0:00.36 0 cc1                                                                  
12612 root      20   0 81172  39m 5192 R  1.0  0.5   0:00.33 0 cc1                                                                  
12615 root      20   0 81160  38m 4360 R  1.0  0.5   0:00.33 0 cc1                                                                  




  reply	other threads:[~2011-01-21 22:27 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-21 18:20 'autogroup' sched code KILLING responsiveness Michael Witten
2011-01-21 22:27 ` Mike Galbraith [this message]
2011-01-21 22:39   ` Michael Witten
2011-01-22  3:22     ` Mike Galbraith
2011-01-22 21:23   ` Michael Witten
2011-01-23  3:32     ` Michael Witten
2011-01-23  5:42       ` Mike Galbraith
2011-01-23 10:50 ` Christian Kujau
2011-01-23 11:19   ` Christian Kujau
2011-01-23 14:54   ` Yong Zhang
2011-01-23 15:03     ` [PATCH] sched: fix autogroup nice tune on UP Yong Zhang
2011-01-23 15:16       ` Pekka Enberg
2011-01-24  3:17         ` Yong Zhang
2011-01-24  5:40       ` [PATCH V2] " Yong Zhang
2011-01-24  5:54         ` Pekka Enberg
2011-01-24  6:11           ` Yong Zhang
2011-01-24  6:18             ` Pekka Enberg
2011-01-24  7:33               ` [PATCH V3] " Yong Zhang
2011-01-24  8:01                 ` Pekka Enberg
2011-01-24  9:00                 ` Mike Galbraith
2011-01-24 10:51                 ` [tip:sched/urgent] sched: Fix poor interactivity on UP systems due to group scheduler nice tune bug tip-bot for Yong Zhang
2011-01-23 15:15     ` 'autogroup' sched code KILLING responsiveness Ingo Molnar
2011-01-23 15:53       ` Michael Witten
2011-01-23 18:52       ` Andreas Mohr
2011-01-23 23:57       ` Christian Kujau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1295648870.23779.15.camel@marge.simson.net \
    --to=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mfwitten@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox