Re: [patch 4/4] create and destroy cpufreq sysfs entries based on cpu notifiers.

[Nathan Lynch <ntl@pobox.com>]

Hi Ashok,

Ashok Raj wrote:
> cpufreq entries in sysfs should only be populated when CPU is online state.
> When we either boot with maxcpus=x and then boot the other cpus by 
> echoing to sysfs online file, these entries should be created and destroyed
> when CPU_DEAD is notified. Same treatement as cache entries under sysfs.
> 
> We place the processor in the lowest frequency, so hw managed P-State 
> transitions can still work on the other threads to save power.
> 
> Primary goal was to just make these directories appear/disapper dynamically.

I see this patch series has already been merged, but in light of the
issues that it has caused[1], and the hack that Andrew is carrying to
deal with them[2], could we revisit the original justification for
these changes?

Why is it important that cpufreq-related files in sysfs be added and
removed as cpus go online and offline?  I see that the information
that these entries provide can be derived only when the cpu is online,
is that the primary justification?

Would it be undesirable for the cpufreq drivers to create their
entries under all cpu sysdevs at init time, regardless of whether the
cpus are online?  The "show" methods for entries attached to offline
cpus could be made to return "Unavailable" or some equivalent.

I'm not terribly familiar with x86 or cpufreq, so forgive me if I'm
missing something obvious.


[1] http://lkml.org/lkml/2005/10/31/144
[2] ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14/2.6.14-mm1/broken-out/cpu-hotplug-fix-locking-in-cpufreq-drivers.patch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/