Re: [PATCH 00/28] PM: QoS: Get rid of unuseful code and rework CPU latency QoS interface

From: Francisco Jerez
Date: Mon Feb 24 2020 - 16:06:31 EST


"Rafael J. Wysocki" <rafael@xxxxxxxxxx> writes:

> On Fri, Feb 21, 2020 at 11:10 PM Francisco Jerez <currojerez@xxxxxxxxxx> wrote:
>>
>> "Rafael J. Wysocki" <rafael@xxxxxxxxxx> writes:
>>
>> > On Thu, Feb 13, 2020 at 9:09 AM Francisco Jerez <currojerez@xxxxxxxxxx> wrote:
>> >>
>> >> "Rafael J. Wysocki" <rafael@xxxxxxxxxx> writes:
>> >>
>> >> > On Thu, Feb 13, 2020 at 1:16 AM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
>> >> >>
>> >> >> On Thu, Feb 13, 2020 at 12:31 AM Francisco Jerez <currojerez@xxxxxxxxxx> wrote:
>> >> >> >
>> >
>> > [cut]
>> >
>> >> >
>> >> > And BTW, posting patches as RFC is fine even if they have not been
>> >> > tested. At least you let people know that you work on something this
>> >> > way, so if they work on changes in the same area, they may take that
>> >> > into consideration.
>> >> >
>> >>
>> >> Sure, that was going to be the first RFC.
>> >>
>> >> > Also if there are objections to your proposal, you may save quite a
>> >> > bit of time by sending it early.
>> >> >
>> >> > It is unfortunate that this series has clashed with the changes that
>> >> > you were about to propose, but in this particular case in my view it
>> >> > is better to clean up things and start over.
>> >> >
>> >>
>> >> Luckily it doesn't clash with the second RFC I was meaning to send,
>> >> maybe we should just skip the first?
>> >
>> > Yes, please.
>> >
>> >> Or maybe it's valuable as a curiosity anyway?
>> >
>> > No, let's just focus on the latest one.
>> >
>> > Thanks!
>>
>> We don't seem to have reached much of an agreement on the general
>> direction of RFC2, so I can't really get started with it. Here is RFC1
>> for the record:
>>
>> https://github.com/curro/linux/commits/intel_pstate-lp-hwp-v10.8-alt
>
> Appreciate the link, but that hasn't been posted to linux-pm yet, so
> there's not much to discuss.
>
> And when you post it, please rebase it on top of linux-next.
>
>> Specifically the following patch conflicts with this series:
>>
>> https://github.com/curro/linux/commit/9a16f35531bbb76d38493da892ece088e31dc2e0
>>
>> Series improves performance-per-watt of GfxBench gl_4 (AKA Car Chase) by
>> over 15% on my system with the branch above, actual FPS "only" improves
>> about 5.9% on ICL laptop due to it being very lightly TDP-bound with its
>> rather huge TDP. The performance of almost every graphics benchmark
>> I've tried improves significantly with it (a number of SynMark
>> test-cases are improved by around 40% in perf-per-watt, Egypt
>> perf-per-watt improves by about 25%).
>>
>> Hopefully we can come up with some alternative plan of action.
>
> It is very easy to replace the patch above with an alternative one on
> top of linux-next that will add CPU_RESPONSE_FREQUENCY QoS along the
> lines of the CPU latency QoS implementation in there without the need
> restore to global QoS classes.
>
> IOW, you don't really need the code that goes away in linux-next to
> implement what you need.
>
> Thanks!

Sure, I'll do that.

Attachment: signature.asc
Description: PGP signature