2.6.23-mm1 breaks C-state support on Intel T7200 x86_64 - Kernel

This is a discussion on 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64 - Kernel ; (Sorry for not reporting this sooner - I haven't been running off battery much in the last 3 weeks, so I didn't notice it till now...) Dell Latitude D820 laptop, T7200 Core2 Duo CPU, x86_64 kernel. As reported by 'powertop' ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

  1. 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

    (Sorry for not reporting this sooner - I haven't been running off battery
    much in the last 3 weeks, so I didn't notice it till now...)

    Dell Latitude D820 laptop, T7200 Core2 Duo CPU, x86_64 kernel.

    As reported by 'powertop' on a basically idle machine:

    2.6.23-mm1:

    Cn Avg residency P-states (frequencies)
    C0 (cpu running) (100.0%) 2.00 Ghz 0.8%
    C1 0.0ms ( 0.0%) 1.67 Ghz 0.0%
    C2 0.0ms ( 0.0%) 1333 Mhz 0.0%
    C3 0.0ms ( 0.0%) 1000 Mhz 99.2%

    2.6.23-rc8-mm2:

    Cn Avg residency P-states (frequencies)
    C0 (cpu running) ( 0.3%) 2.00 Ghz 0.0%
    C1 0.0ms ( 0.0%) 1.67 Ghz 0.0%
    C2 0.0ms ( 0.0%) 1333 Mhz 0.0%
    C3 31.5ms (99.7%) 1000 Mhz 100.0%

    In addition, the ACPI power estimate reported about 25 watts for 23-mm1,
    but only 21 watts for -rc8-mm2, a significant regression.

    I bisected this down to this set of patches:

    pm-qos-infrastructure-and-interface.patch
    pm-qos-infrastructure-and-interface-fix.patch
    pm-qos-infrastructure-and-interface-vs-git-acpi.patch
    pm-qos-infrastructure-and-interface-vs-git-acpi-2.patch
    latencyc-use-qos-infrastructure.patch

    The patch says:

    To register the default pm_qos target for the specific parameter, the
    process must open one of /dev/[cpu_dma_latency, network_latency,
    network_throughput]

    As long as the device node is held open that process has a registered
    requirement on the parameter. The name of the requirement is
    "process_" derived from the current->pid from within the open system
    call.

    I shouldn't have to have a process open a /dev/file, write a number, and then
    stay around forever so the file doesn't close in order to get the same behavior
    I was getting by default before. What needs to happen to get this to not
    be a behavior regression/change?





    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (GNU/Linux)
    Comment: Exmh version 2.5 07/13/2001

    iD8DBQFHM0UwcC3lWbTT17ARAht9AKCGHKp43NZXYB6rZwGk4v aWJHeU9wCgzqG3
    iF9ZKXsWsXlvnvj+Pu8/r7k=
    =XTrD
    -----END PGP SIGNATURE-----


  2. Re: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

    > On Thu, 08 Nov 2007 12:19:44 -0500 Valdis.Kletnieks@vt.edu wrote:
    > (Sorry for not reporting this sooner - I haven't been running off battery
    > much in the last 3 weeks, so I didn't notice it till now...)
    >
    > Dell Latitude D820 laptop, T7200 Core2 Duo CPU, x86_64 kernel.
    >
    > As reported by 'powertop' on a basically idle machine:
    >
    > 2.6.23-mm1:
    >
    > Cn Avg residency P-states (frequencies)
    > C0 (cpu running) (100.0%) 2.00 Ghz 0.8%
    > C1 0.0ms ( 0.0%) 1.67 Ghz 0.0%
    > C2 0.0ms ( 0.0%) 1333 Mhz 0.0%
    > C3 0.0ms ( 0.0%) 1000 Mhz 99.2%
    >
    > 2.6.23-rc8-mm2:
    >
    > Cn Avg residency P-states (frequencies)
    > C0 (cpu running) ( 0.3%) 2.00 Ghz 0.0%
    > C1 0.0ms ( 0.0%) 1.67 Ghz 0.0%
    > C2 0.0ms ( 0.0%) 1333 Mhz 0.0%
    > C3 31.5ms (99.7%) 1000 Mhz 100.0%
    >
    > In addition, the ACPI power estimate reported about 25 watts for 23-mm1,
    > but only 21 watts for -rc8-mm2, a significant regression.
    >
    > I bisected this down to this set of patches:
    >
    > pm-qos-infrastructure-and-interface.patch
    > pm-qos-infrastructure-and-interface-fix.patch
    > pm-qos-infrastructure-and-interface-vs-git-acpi.patch
    > pm-qos-infrastructure-and-interface-vs-git-acpi-2.patch
    > latencyc-use-qos-infrastructure.patch
    >
    > The patch says:
    >
    > To register the default pm_qos target for the specific parameter, the
    > process must open one of /dev/[cpu_dma_latency, network_latency,
    > network_throughput]
    >
    > As long as the device node is held open that process has a registered
    > requirement on the parameter. The name of the requirement is
    > "process_" derived from the current->pid from within the open system
    > call.
    >
    > I shouldn't have to have a process open a /dev/file, write a number, and then
    > stay around forever so the file doesn't close in order to get the same behavior
    > I was getting by default before. What needs to happen to get this to not
    > be a behavior regression/change?
    >


    That's a great report, thanks. Over to you, Mark

    btw, I also have a note here that these patches caused Rafael to see an
    smp_call_function() inside local_irq_save(). Did that get fixed?
    -
    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/

  3. Re: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

    On Thu, Nov 08, 2007 at 12:19:44PM -0500, Valdis.Kletnieks@vt.edu wrote:
    > (Sorry for not reporting this sooner - I haven't been running off battery
    > much in the last 3 weeks, so I didn't notice it till now...)
    >
    > Dell Latitude D820 laptop, T7200 Core2 Duo CPU, x86_64 kernel.
    >
    > As reported by 'powertop' on a basically idle machine:
    >
    > 2.6.23-mm1:
    >
    > Cn Avg residency P-states (frequencies)
    > C0 (cpu running) (100.0%) 2.00 Ghz 0.8%
    > C1 0.0ms ( 0.0%) 1.67 Ghz 0.0%
    > C2 0.0ms ( 0.0%) 1333 Mhz 0.0%
    > C3 0.0ms ( 0.0%) 1000 Mhz 99.2%
    >
    > 2.6.23-rc8-mm2:
    >
    > Cn Avg residency P-states (frequencies)
    > C0 (cpu running) ( 0.3%) 2.00 Ghz 0.0%
    > C1 0.0ms ( 0.0%) 1.67 Ghz 0.0%
    > C2 0.0ms ( 0.0%) 1333 Mhz 0.0%
    > C3 31.5ms (99.7%) 1000 Mhz 100.0%
    >
    > In addition, the ACPI power estimate reported about 25 watts for 23-mm1,
    > but only 21 watts for -rc8-mm2, a significant regression.


    well, thats because you burn less watts if you get into C3.

    >
    > I bisected this down to this set of patches:
    >
    > pm-qos-infrastructure-and-interface.patch
    > pm-qos-infrastructure-and-interface-fix.patch
    > pm-qos-infrastructure-and-interface-vs-git-acpi.patch
    > pm-qos-infrastructure-and-interface-vs-git-acpi-2.patch
    > latencyc-use-qos-infrastructure.patch


    yipes! I'll look at it right away. It looks like an integration issue
    with CPU-IDLE patches (those control the C-state entry). I'll get it
    fixed up.

    >
    > The patch says:
    >
    > To register the default pm_qos target for the specific parameter, the
    > process must open one of /dev/[cpu_dma_latency, network_latency,
    > network_throughput]
    >
    > As long as the device node is held open that process has a registered
    > requirement on the parameter. The name of the requirement is
    > "process_" derived from the current->pid from within the open system
    > call.
    >
    > I shouldn't have to have a process open a /dev/file, write a number, and then
    > stay around forever so the file doesn't close in order to get the same behavior
    > I was getting by default before. What needs to happen to get this to not
    > be a behavior regression/change?
    >

    you won't have such a process (at least I highly doubt you do) I need
    to fix this. Thanks for taking the time to bisect it and reporting it to me!

    --mgross
    -
    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/

  4. Re: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

    On Thu, Nov 08, 2007 at 10:02:12AM -0800, Andrew Morton wrote:
    > > On Thu, 08 Nov 2007 12:19:44 -0500 Valdis.Kletnieks@vt.edu wrote:
    > > (Sorry for not reporting this sooner - I haven't been running off battery
    > > much in the last 3 weeks, so I didn't notice it till now...)
    > >
    > > Dell Latitude D820 laptop, T7200 Core2 Duo CPU, x86_64 kernel.
    > >
    > > As reported by 'powertop' on a basically idle machine:
    > >
    > > 2.6.23-mm1:
    > >
    > > Cn Avg residency P-states (frequencies)
    > > C0 (cpu running) (100.0%) 2.00 Ghz 0.8%
    > > C1 0.0ms ( 0.0%) 1.67 Ghz 0.0%
    > > C2 0.0ms ( 0.0%) 1333 Mhz 0.0%
    > > C3 0.0ms ( 0.0%) 1000 Mhz 99.2%
    > >
    > > 2.6.23-rc8-mm2:
    > >
    > > Cn Avg residency P-states (frequencies)
    > > C0 (cpu running) ( 0.3%) 2.00 Ghz 0.0%
    > > C1 0.0ms ( 0.0%) 1.67 Ghz 0.0%
    > > C2 0.0ms ( 0.0%) 1333 Mhz 0.0%
    > > C3 31.5ms (99.7%) 1000 Mhz 100.0%
    > >
    > > In addition, the ACPI power estimate reported about 25 watts for 23-mm1,
    > > but only 21 watts for -rc8-mm2, a significant regression.
    > >
    > > I bisected this down to this set of patches:
    > >
    > > pm-qos-infrastructure-and-interface.patch
    > > pm-qos-infrastructure-and-interface-fix.patch
    > > pm-qos-infrastructure-and-interface-vs-git-acpi.patch
    > > pm-qos-infrastructure-and-interface-vs-git-acpi-2.patch
    > > latencyc-use-qos-infrastructure.patch
    > >
    > > The patch says:
    > >
    > > To register the default pm_qos target for the specific parameter, the
    > > process must open one of /dev/[cpu_dma_latency, network_latency,
    > > network_throughput]
    > >
    > > As long as the device node is held open that process has a registered
    > > requirement on the parameter. The name of the requirement is
    > > "process_" derived from the current->pid from within the open system
    > > call.
    > >
    > > I shouldn't have to have a process open a /dev/file, write a number, and then
    > > stay around forever so the file doesn't close in order to get the same behavior
    > > I was getting by default before. What needs to happen to get this to not
    > > be a behavior regression/change?
    > >

    >
    > That's a great report, thanks. Over to you, Mark
    >
    > btw, I also have a note here that these patches caused Rafael to see an
    > smp_call_function() inside local_irq_save(). Did that get fixed?


    Ah, I see the problem. I think I posted a fix to this. The problem is
    that what's in the mm1 tree has a parameter PM_QOS_IDLE that needed to
    be PM_QOS_CPU_DMA_LATENCY.

    I'm not sure what's in the current MM tree at this point so I can't say
    its been fixed. Is there an easy way from me to see what's currently in
    MM?

    FWIW I think I fixed this when I fixed up Rafael's issue. Would you
    like me to send out a re-fresh patch against 2.6.23-mm1?

    --mgross

    -
    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/

  5. Re: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

    > On Thu, 8 Nov 2007 12:03:52 -0800 Mark Gross wrote:
    > ...
    > > > call.
    > > >
    > > > I shouldn't have to have a process open a /dev/file, write a number, and then
    > > > stay around forever so the file doesn't close in order to get the same behavior
    > > > I was getting by default before. What needs to happen to get this to not
    > > > be a behavior regression/change?
    > > >

    > >
    > > That's a great report, thanks. Over to you, Mark
    > >
    > > btw, I also have a note here that these patches caused Rafael to see an
    > > smp_call_function() inside local_irq_save(). Did that get fixed?

    >
    > Ah, I see the problem. I think I posted a fix to this. The problem is
    > that what's in the mm1 tree has a parameter PM_QOS_IDLE that needed to
    > be PM_QOS_CPU_DMA_LATENCY.


    That doesn't ring a bell.

    > I'm not sure what's in the current MM tree at this point so I can't say
    > its been fixed. Is there an easy way from me to see what's currently in
    > MM?


    Not terribly.
    ftp://ftp.kernel.org/pub/linux/kerne...6-02-32.tar.gz
    is from two days ago.

    > FWIW I think I fixed this when I fixed up Rafael's issue. Would you
    > like me to send out a re-fresh patch against 2.6.23-mm1?


    sure.
    -
    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/

  6. Re: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

    On Thu, Nov 08, 2007 at 12:19:44PM -0500, Valdis.Kletnieks@vt.edu wrote:
    > (Sorry for not reporting this sooner - I haven't been running off battery
    > much in the last 3 weeks, so I didn't notice it till now...)
    >
    > Dell Latitude D820 laptop, T7200 Core2 Duo CPU, x86_64 kernel.
    >
    > As reported by 'powertop' on a basically idle machine:
    >
    > 2.6.23-mm1:
    >
    > Cn Avg residency P-states (frequencies)
    > C0 (cpu running) (100.0%) 2.00 Ghz 0.8%
    > C1 0.0ms ( 0.0%) 1.67 Ghz 0.0%
    > C2 0.0ms ( 0.0%) 1333 Mhz 0.0%
    > C3 0.0ms ( 0.0%) 1000 Mhz 99.2%
    >
    > 2.6.23-rc8-mm2:
    >
    > Cn Avg residency P-states (frequencies)
    > C0 (cpu running) ( 0.3%) 2.00 Ghz 0.0%
    > C1 0.0ms ( 0.0%) 1.67 Ghz 0.0%
    > C2 0.0ms ( 0.0%) 1333 Mhz 0.0%
    > C3 31.5ms (99.7%) 1000 Mhz 100.0%
    >
    > In addition, the ACPI power estimate reported about 25 watts for 23-mm1,
    > but only 21 watts for -rc8-mm2, a significant regression.
    >
    > I bisected this down to this set of patches:
    >
    > pm-qos-infrastructure-and-interface.patch
    > pm-qos-infrastructure-and-interface-fix.patch
    > pm-qos-infrastructure-and-interface-vs-git-acpi.patch
    > pm-qos-infrastructure-and-interface-vs-git-acpi-2.patch
    > latencyc-use-qos-infrastructure.patch
    >
    > The patch says:
    >
    > To register the default pm_qos target for the specific parameter, the
    > process must open one of /dev/[cpu_dma_latency, network_latency,
    > network_throughput]
    >
    > As long as the device node is held open that process has a registered
    > requirement on the parameter. The name of the requirement is
    > "process_" derived from the current->pid from within the open system
    > call.
    >
    > I shouldn't have to have a process open a /dev/file, write a number, and then
    > stay around forever so the file doesn't close in order to get the same behavior
    > I was getting by default before. What needs to happen to get this to not
    > be a behavior regression/change?
    >
    >
    >
    >


    wing patch fixes up the cpuidle / pm-qos integration.

    I suspect that this is folded into another mm patch but it should fix
    C-state issue identified.

    --mgross



    Signed-off-by: mark gross

    -------------

    Index: linux-2.6.23-mm1/drivers/cpuidle/cpuidle.c
    ================================================== =================
    --- linux-2.6.23-mm1.orig/drivers/cpuidle/cpuidle.c 2007-11-08 13:09:53.000000000 -0800
    +++ linux-2.6.23-mm1/drivers/cpuidle/cpuidle.c 2007-11-08 13:25:13.000000000 -0800
    @@ -268,7 +268,7 @@

    static inline void latency_notifier_init(struct notifier_block *n)
    {
    - pm_qos_add_notifier(PM_QOS_CPUIDLE, n);
    + pm_qos_add_notifier(PM_QOS_CPU_DMA_LATENCY, n);
    }

    #else /* CONFIG_SMP */
    Index: linux-2.6.23-mm1/drivers/cpuidle/governors/ladder.c
    ================================================== =================
    --- linux-2.6.23-mm1.orig/drivers/cpuidle/governors/ladder.c 2007-11-08 13:09:53.000000000 -0800
    +++ linux-2.6.23-mm1/drivers/cpuidle/governors/ladder.c 2007-11-08 13:11:30.000000000 -0800
    @@ -82,7 +82,7 @@
    if (last_idx < dev->state_count - 1 &&
    last_residency > last_state->threshold.promotion_time &&
    dev->states[last_idx + 1].exit_latency <=
    - pm_qos_requirement(PM_QOS_CPUIDLE)) {
    + pm_qos_requirement(PM_QOS_CPU_DMA_LATENCY)) {
    last_state->stats.promotion_count++;
    last_state->stats.demotion_count = 0;
    if (last_state->stats.promotion_count >= last_state->threshold.promotion_count) {
    Index: linux-2.6.23-mm1/drivers/cpuidle/governors/menu.c
    ================================================== =================
    --- linux-2.6.23-mm1.orig/drivers/cpuidle/governors/menu.c 2007-11-08 13:12:11.000000000 -0800
    +++ linux-2.6.23-mm1/drivers/cpuidle/governors/menu.c 2007-11-08 13:24:03.000000000 -0800
    @@ -48,7 +48,8 @@
    break;
    if (s->target_residency > data->predicted_us)
    break;
    - if (s->exit_latency > pm_qos_requirement(PM_QOS_CPUIDLE))
    + if (s->exit_latency >
    + pm_qos_requirement(PM_QOS_CPU_DMA_LATENCY))
    break;
    }

    Index: linux-2.6.23-mm1/include/linux/pm_qos_params.h
    ================================================== =================
    --- linux-2.6.23-mm1.orig/include/linux/pm_qos_params.h 2007-11-08 13:09:53.000000000 -0800
    +++ linux-2.6.23-mm1/include/linux/pm_qos_params.h 2007-11-08 13:14:05.000000000 -0800
    @@ -6,23 +6,12 @@
    #include
    #include

    -struct requirement_list {
    - struct list_head list;
    - union {
    - s32 value;
    - s32 usec;
    - s32 kbps;
    - };
    - char *name;
    -};
    -
    #define PM_QOS_RESERVED 0
    #define PM_QOS_CPU_DMA_LATENCY 1
    #define PM_QOS_NETWORK_LATENCY 2
    #define PM_QOS_NETWORK_THROUGHPUT 3
    -#define PM_QOS_CPUIDLE 4

    -#define PM_QOS_NUM_CLASSES 5
    +#define PM_QOS_NUM_CLASSES 4
    #define PM_QOS_DEFAULT_VALUE -1

    int pm_qos_add_requirement(int qos, char *name, s32 value);
    Index: linux-2.6.23-mm1/kernel/pm_qos_params.c
    ================================================== =================
    --- linux-2.6.23-mm1.orig/kernel/pm_qos_params.c 2007-11-08 13:09:54.000000000 -0800
    +++ linux-2.6.23-mm1/kernel/pm_qos_params.c 2007-11-08 13:14:28.000000000 -0800
    @@ -47,6 +47,16 @@
    * held, taken with _irqsave. One lock to rule them all
    */

    +struct requirement_list {
    + struct list_head list;
    + union {
    + s32 value;
    + s32 usec;
    + s32 kbps;
    + };
    + char *name;
    +};
    +
    struct pm_qos_object {
    struct requirement_list requirements;
    struct srcu_notifier_head notifiers;
    -
    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/

  7. Re: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

    On Thu, 08 Nov 2007 14:30:07 PST, Mark Gross said:

    > wing patch fixes up the cpuidle / pm-qos integration.
    >
    > I suspect that this is folded into another mm patch but it should fix
    > C-state issue identified.


    Confirming that patch left my CPUs mostly in C3 again. Thanks.

    I'll have to let Mark and Andrew figure out this code's status in the -mm queue.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (GNU/Linux)
    Comment: Exmh version 2.5 07/13/2001

    iD8DBQFHNMIMcC3lWbTT17ARAul3AKCdgc9INn6KdQvnlkuNNi xOJauSWgCgmCgm
    SfuMkYaMXG6/9dhntHrDGVo=
    =EJ9/
    -----END PGP SIGNATURE-----


  8. Re: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

    On Fri, Nov 09, 2007 at 03:24:44PM -0500, Valdis.Kletnieks@vt.edu wrote:
    > On Thu, 08 Nov 2007 14:30:07 PST, Mark Gross said:
    >
    > > wing patch fixes up the cpuidle / pm-qos integration.
    > >
    > > I suspect that this is folded into another mm patch but it should fix
    > > C-state issue identified.

    >
    > Confirming that patch left my CPUs mostly in C3 again. Thanks.
    >
    > I'll have to let Mark and Andrew figure out this code's status in the -mm queue.


    I checked on this last week, I'm pretty sure its in Andrew's current
    tree.

    Thanks again for looking at this.

    --mgross
    -
    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/

+ Reply to Thread