mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Anders Bostr?m <anders@bostrom.dyndns.org>,
	linux-kernel@vger.kernel.org, arjan@linux.intel.com
Subject: Re: PROBLEM: high load average when idle
Date: Tue, 2 Oct 2007 15:32:53 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.0.999.0710021514040.3579@woody.linux-foundation.org> (raw)
In-Reply-To: <20071002150748.906970bc.akpm@linux-foundation.org>



On Tue, 2 Oct 2007, Andrew Morton wrote:
> 
> This is unexpected.  High load average is due to either a task chewing a
> lot of CPU time or a task stuck in uninterruptible sleep.

Not necessarily.

We saw high loadaverages with the timer bogosity with "gettimeofday()" and 
"select()" not agreeing, so they would do things like

	date = time(..)
	select(.. , timeout = <time + 1> )

and when "date" wasn't taking the jiffies offset into account, and thus 
mixing these kinds of different time sources, the select ended up 
returning immediately because they effectively used different clocks, and 
suddenly we had some applications chewing up 30% CPU time, because they 
were in a loop that *tried* to sleep.

And I wonder if the same kind thing is effectively happening here: the 
code is written so that it *tries* to sleep, but the rounding of the clock 
basically means that it's trying to sleep using a different clock than the 
one we're using to wake things up with, so some percentage of the time it 
doesn't sleep at all!

I wonder if the whole "round_jiffies()" thing should be written so that it 
never rounds down, or at least never rounds down to before the current 
second!

I have to say, I also think it's a bit iffy to do "round_jiffies()" at all 
in that per-CPU kind of way. The "per-cpu" thing is quite possibly going 
to change by the time we actually add the timer, so the goal of trying to 
get wakeups to happen in "bunches" per CPU should really be done by 
setting a flag on the timer itself - so that we could do that rounding 
when the timer is actually added to the per-cpu queues!

Now, I think the JBD "t_expires" field should never be "near" in seconds, 
so I do find it a bit surprising that this rounding can have any effect, 
but on the other hand it clearly *does* have some effect, so.. It migt 
just be interacting with some other use, of course.

		Linus

  reply	other threads:[~2007-10-02 22:33 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-02 21:37 Anders Boström
2007-10-02 22:07 ` Andrew Morton
2007-10-02 22:32   ` Linus Torvalds [this message]
2007-10-02 22:39     ` Arjan van de Ven
2007-10-02 22:46     ` Mark Lord
2007-10-02 23:22       ` Arjan van de Ven
2007-10-02 23:40         ` Mark Lord
2007-10-02 23:19     ` Arjan van de Ven
2007-10-02 22:33   ` Chuck Ebbert
2007-10-02 23:26     ` Arjan van de Ven
2007-10-03 17:32       ` Chuck Ebbert
2007-10-03 18:02         ` Linus Torvalds
2007-10-03 18:20           ` Arjan van de Ven
2007-10-03 18:28             ` Linus Torvalds
2007-10-03 18:29               ` Arjan van de Ven
2007-10-03 20:15           ` Anders Boström
2007-10-03 18:34   ` Anders Boström
2007-10-02 23:13 ` Arjan van de Ven
2007-10-03  7:04   ` Anders Boström
2007-10-03  9:40 ` Thorsten Kranzkowski

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=alpine.LFD.0.999.0710021514040.3579@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=anders@bostrom.dyndns.org \
    --cc=arjan@linux.intel.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®