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

From: Nathan Lynch (ntl_at_pobox.com)
Date: 11/07/05

  • Next message: Adrian Bunk: "Re: Which version of 2.6.11 is most stable" 
    Date:	Mon, 7 Nov 2005 05:41:44 -0600
To: Ashok Raj <ashok.raj@intel.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/

  • Next message: Adrian Bunk: "Re: Which version of 2.6.11 is most stable"

    Relevant Pages