mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stephane Eranian <eranian@hpl.hp.com>
To: Andi Kleen <ak@suse.de>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org,
	Stephane Eranian <eranian@hpl.hp.com>
Subject: Re: [PATCH] x86_64 add missing enter_idle() calls
Date: Sat, 21 Oct 2006 02:18:37 -0700	[thread overview]
Message-ID: <20061021091837.GA24670@frankl.hpl.hp.com> (raw)
In-Reply-To: <200610161636.52721.ak@suse.de>

Andi,

On Mon, Oct 16, 2006 at 04:36:52PM +0200, Andi Kleen wrote:
> > With the original code, the number of callbacks you see for IDLE_START and
> > IDLE_STOP is not too obvious.
> > 
> > On an idle system Opteron 250 with HZ=250, one would expect to see for a 10s duration:
> > 	- for CPU0      : IDLE_START = IDLE_STOP = about 5000 calls
> > 	- for other CPUs: IDLE_START = IDLE_STOP = about 2500  calls
> 
> Yes.
> 
> > With the original code, you get the following number of calls:
> > 
> > CPU0.IDLE_START = 44 (enter_idle)
> > CPU0.IDLE_STOP  = 5206 (exit_idle)
> > 
> > CPU1.IDLE_START = 27 (enter_idle)
> > CPU1.IDLE_STOP  = 2528 (exit_idle)
> > 
> 
> Hmm, the last time I fixed this when you complained (post .18) i added a counter for 
> entry/exit and verified that it was balanced. I haven't rechecked since then.
> I don't know why your numbers are off. You're using the latest git tree, right?

As I reported earlier, going to the Git kernel did not really change the
number of invocations of the idle notifier. I was very puzzled by this, so I
chased it some more.

I finally found the culprit for this. The current code is wrong for the
simple reason that the cpu_idle() function is NOT always the lowest level
idle loop function. For enter_idle()/__exit_idle() to work correctly they
must be placed in the lowest-level idle loop. The cpu_idle() eventually ends
up in the idle() function, but this one may have a loop in it! This is the
case when idle()=cpu_default_idle() and idle()=poll_idle(), for instance. 

The reason why the idle notifier was called so few times, even though we had
the right number of interrupts, is simply because we were not getting out of
the idle() function. So I can, indeed, confirm that an interrupt in HLT
instruction gets you out, but HLT is in a loop from which you do not get out
unless you need to reschedule. By moving enter_idle()/__exit_idle() to
cpu_default_idle() I got the right number of calls for the idle notifier.

I see two solutions to this:
	- move enter_idle()/__exit_idle() to the actual lowest-level loop,
	  in cpu_default_idle() and not in cpu_idle(). We would also have
	  to do something similar to poll_idle(), or any similar idle function
	  which contains a loop.

	- add exit_idle() to all the local interrupt handlers, like my
	  initial patch was doing and leave the ente_idle()/__exit_idle()
	  where they are today.

-- 
-Stephane

  parent reply	other threads:[~2006-10-21  9:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-06  8:16 Stephane Eranian
2006-10-16 10:08 ` Andi Kleen
2006-10-16 14:13   ` Stephane Eranian
2006-10-16 14:36     ` Andi Kleen
2006-10-16 14:44       ` Stephane Eranian
2006-10-17 16:47       ` Stephane Eranian
2006-10-21  9:18       ` Stephane Eranian [this message]
2006-10-21 13:22         ` Andi Kleen
2006-10-24 10:00           ` Stephane Eranian
2006-10-25 21:29           ` Stephane Eranian
2006-10-27 16:03             ` Andi Kleen

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=20061021091837.GA24670@frankl.hpl.hp.com \
    --to=eranian@hpl.hp.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --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

Powered by JetHome