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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0jqp7aEh43kUvxyMWxbnEUjUZZ31iHk_oxDdvGM6RTdMw@mail.gmail.com>
Date:   Mon, 24 Feb 2020 01:29:10 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Francisco Jerez <currojerez@...eup.net>
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

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!