[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87lforelv3.fsf@riseup.net>
Date: Mon, 24 Feb 2020 13:06:24 -0800
From: Francisco Jerez <currojerez@...eup.net>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Linux PM <linux-pm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Amit Kucheria <amit.kucheria@...aro.org>,
"Pandruvada\, Srinivas" <srinivas.pandruvada@...el.com>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH 00/28] PM: QoS: Get rid of unuseful code and rework CPU latency QoS interface
"Rafael J. Wysocki" <rafael@...nel.org> writes:
> On Fri, Feb 21, 2020 at 11:10 PM Francisco Jerez <currojerez@...eup.net> wrote:
>>
>> "Rafael J. Wysocki" <rafael@...nel.org> writes:
>>
>> > On Thu, Feb 13, 2020 at 9:09 AM Francisco Jerez <currojerez@...eup.net> wrote:
>> >>
>> >> "Rafael J. Wysocki" <rafael@...nel.org> writes:
>> >>
>> >> > On Thu, Feb 13, 2020 at 1:16 AM Rafael J. Wysocki <rafael@...nel.org> wrote:
>> >> >>
>> >> >> On Thu, Feb 13, 2020 at 12:31 AM Francisco Jerez <currojerez@...eup.net> 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.
Download attachment "signature.asc" of type "application/pgp-signature" (228 bytes)
Powered by blists - more mailing lists