All of lore.kernel.org
 help / color / mirror / Atom feed
From: Prarit Bhargava <prarit@redhat.com>
To: Thomas Renninger <trenn@suse.de>
Cc: Jacob Tanenbaum <jtanenba@redhat.com>, linux-pm@vger.kernel.org
Subject: Re: cpupower reports uninitialized values for offline cpus
Date: Wed, 30 Sep 2015 14:25:47 -0400	[thread overview]
Message-ID: <560C292B.5030905@redhat.com> (raw)
In-Reply-To: <2397035.37ChXSYNtU@skinner>



On 09/30/2015 12:23 PM, Thomas Renninger wrote:
> On Tuesday, September 29, 2015 04:25:47 PM Prarit Bhargava wrote:
>> On 09/29/2015 02:58 PM, Jacob Tanenbaum wrote:
>>> Hi guys,
>>>
>>> I have found a bug in the cpupower tool. In the most recent pull of
>>> linus's tree cpupower reports bogus information for offlined cpus.
> ...
>> Thomas,
>>
>> I'm not sure I see any benefit in reporting the offline cpu status here.
> There have been discussions to use CPU offlining as a power saving mechanism.

Yeah, I think in the past that this suggestion had been made but ISTR some
question as to exactly how much power would be saved in a "soft-remove" scenario
for a core & socket, and if there is any real benefit.

> This is afaik no real option on x86, at least not too frequent, but it could
> be on other archs?
> So the info would be nice to have...
> 
>> We
>> could I suppose output a message at the beginning of the output to indicate
>> that some cpus have been hotplugged, but I'm not sure that is even
>> necessary.
> Yep, just that people do not complain that cores are missing...
> May make sense.

Ok -- let's go with that for now, post, and see if anyone complains loudly about
that "loss" of info.  Jake, are you comfortable with that?

>>
>>>   3. Change the sysfs to retain topology data for offlined cpus, may
>>>   require
> 
> I had a quick look. I think this could be done.
> /sys/devices/system/cpu/cpu*/cpuidle
> also is kept, not sure why, because I cannot see any advantage to access
> this info on an offlined CPU.
> 

I think I see the problem.  When the intel_idle driver is loaded it registers a
cpu hotplug notifier, cpu_hotplug_notify(), which registers (and creates the
sysfs cpuidle dir) as each cpu is created.  This is done via a call to
intel_idle_cpu_init(), which calls cpuidle_register_device().

The reverse isn't true, however, and AFAICT, _all_ the cpuidle directories are
only destroyed when the driver is unloaded in intel_idle_exit().

I think that's a bug too FWIW, and I agree -- there isn't any point in having
that data lying around.

> But reading the topology of offlined CPUs makes sense.
> Argh, but yes. For real on-/offlining this is hard...

Yeah, we'd have to add an additional state to the CPU hotplug callback state
machine (CPU_ADD_PHYSICAL?) to identify when a cpu was hot-added.  I suppose it
could be done but it seems like an awful lot of churn for little gain.

P.

  reply	other threads:[~2015-09-30 18:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-29 18:58 cpupower reports uninitialized values for offline cpus Jacob Tanenbaum
2015-09-29 20:25 ` Prarit Bhargava
2015-09-30 16:23   ` Thomas Renninger
2015-09-30 18:25     ` Prarit Bhargava [this message]
2015-10-01 12:29       ` Thomas Renninger
2015-10-01 13:11         ` Prarit Bhargava

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=560C292B.5030905@redhat.com \
    --to=prarit@redhat.com \
    --cc=jtanenba@redhat.com \
    --cc=linux-pm@vger.kernel.org \
    --cc=trenn@suse.de \
    /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.