[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJvTdKmi2pfE+fn5-MVd8T5_0j+EbASJ992AYmVKG2osk762yQ@mail.gmail.com>
Date: Thu, 24 Mar 2016 17:54:05 -0400
From: Len Brown <lenb@...nel.org>
To: Prarit Bhargava <prarit@...hat.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
X86 ML <x86@...nel.org>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
Borislav Petkov <bp@...e.de>, Andi Kleen <ak@...ux.intel.com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Dasaratharaman Chandramouli
<dasaratharaman.chandramouli@...el.com>,
Linux PM list <linux-pm@...r.kernel.org>
Subject: Re: [PATCH 0/3] idle, Honor Hardware Disabled States
On Wed, Mar 23, 2016 at 7:50 PM, Prarit Bhargava <prarit@...hat.com> wrote:
>
>
> On 03/23/2016 04:05 PM, Len Brown wrote:
>> This patch assumes that if a package state is disabled,
>> the corresponding core state must be disabled.
>> That assumption is false.
>> Indeed, that is a very popular and useful configuration.
>>
>> But even if that were not the case, this software is not necessary,
>> since the hardware handles demotion "c-state clipping" automatically.
>>
>> Yes, there is a case where a certain version of a certain processor
>> has broken demotion, but this isn't the right fix for that.
>> The right fix for that is here:
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=109081
>
> Len, should I rebase on top of this? Would that work for you?
I guess I wasn't clear.
I don't see the benefit of your patch.
Please explain it to me.
thanks,
-Len
Powered by blists - more mailing lists