All of lore.kernel.org
 help / color / mirror / Atom feed
From: tmhikaru@gmail.com
To: Greg KH <gregkh@suse.de>, linux-kernel@vger.kernel.org
Subject: Re: Linux 2.6.35.6
Date: Mon, 27 Sep 2010 12:32:08 -0400	[thread overview]
Message-ID: <20100927163208.GA4892@roll> (raw)
In-Reply-To: <20100927003608.GA20395@kroah.com>

[-- Attachment #1: Type: text/plain, Size: 1815 bytes --]

	I'm not exactly sure what's going on here and I'd like some help
figuring out what is. For some inexplicable reason, ever since I started
using the 2.6.35.x series with the 2.6.35.3 release, my loadaverages tend to
bounce anywhere from as low to .2 to 1.5 - constantly, while the machine
seems idle. Consistently, there are no programs in D state in ps aux output,
no cpu hogging programs running in top, nothing I can see that should
explain the bizzarely high load average. *Something* is wrong beyond the
mere loadaverage numbers going crazy however, since timed runs of kernel
compiles done with my distro's kernel and 2.6.35.5 show that while there is
no *apparent* use of cpu or disk showing in vmstat while the machine is
idle, the compiles on the newer kernel are taking approximately twice as
long as before. Now, while I could try to figure out what patch started the
problem, I think it would be a better idea for me to make sure I'm looking
for the actual problem in the right place. Therefore, I know that cpu use,
disk I/O, and the kernel can drive the load average up. Of these things, cpu
use and disk I/O are trackable in top/ps output (eg, a process in D state is
waiting on the disk to do something and can't sleep.) but I don't know if
there's any easy way to determine if the kernel itself is doing something
that's driving up the load average. It's perplexing me that I can see the
loadaverage constantly bouncing about but can't seem to find any reason why
it is doing so.

	If you have any tips or recommendations on what I should use to
investigate this further, please let me know. Once I have ensured to my own
satisfaction that I'm not doing something bizzare that's screwing up my
machine, I'll make a detailed bug report and start on figuring out how to
use git bisect.

	Tim McGrath

[-- Attachment #2: Type: application/pgp-signature, Size: 482 bytes --]

  parent reply	other threads:[~2010-09-27 16:32 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-27  0:36 Linux 2.6.35.6 Greg KH
2010-09-27  0:36 ` Greg KH
2010-09-27  1:00 ` Felipe Contreras
2010-09-27  1:31   ` Greg KH
2010-09-27 17:05     ` Felipe Contreras
2010-09-27 16:32 ` tmhikaru [this message]
2010-09-27 17:54   ` Greg KH
2010-09-27 19:09     ` tmhikaru
2010-09-27 19:51   ` Florian Mickler
2010-09-27 23:39     ` tmhikaru
2010-09-28  4:45       ` tmhikaru
2010-09-28  6:35       ` Florian Mickler
2010-09-28 19:03         ` tmhikaru
2010-09-29  7:29           ` Florian Mickler
2010-09-29 11:02             ` tmhikaru
2010-09-29 11:33               ` Miguel Ojeda
2010-09-29 11:52               ` Florian Mickler
2010-09-29 12:19                 ` Florian Mickler
2010-09-30  1:33                 ` tmhikaru
2010-09-30  5:29                   ` Florian Mickler
2010-09-30  7:38                     ` tmhikaru

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=20100927163208.GA4892@roll \
    --to=tmhikaru@gmail.com \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.