linux-kernel - Re: [PATCH 2/3] cpufreq: schedutil: move slow path from workqueue to SCHED

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20161114092252.GT3117@twins.programming.kicks-ass.net>
Date:   Mon, 14 Nov 2016 10:22:52 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Tommaso Cucinotta <tommaso.cucinotta@...up.it>,
        Rafael Wysocki <rjw@...ysocki.net>,
        Ingo Molnar <mingo@...hat.com>,
        Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Juri Lelli <Juri.Lelli@....com>,
        Robin Randhawa <robin.randhawa@....com>,
        Steve Muckle <smuckle.linux@...il.com>
Subject: Re: [PATCH 2/3] cpufreq: schedutil: move slow path from workqueue to
 SCHED_FIFO task

On Sat, Nov 12, 2016 at 10:52:35AM +0530, Viresh Kumar wrote:
> On 11 November 2016 at 20:09, Peter Zijlstra <peterz@...radead.org> wrote:
> > On Fri, Nov 11, 2016 at 03:32:04PM +0100, Tommaso Cucinotta wrote:
> >> >+    struct sched_param param = { .sched_priority = 50 };
> >>
> >> won't you have a tunable here? (sysctl?)
> >
> > You can use the regular userspace tools, like schedtool and chrt to set
> > priorities.
> 
> I wanted to get some help from you on this Peter. The out of tree Interactive
> governor has always used MAX_RT_PRIORITY - 1 here instead of 50.
> 
> But Steve started with 50. What do you think should the value be ?

Any static prio value is wrong (static prio assignment requires system
knowledge that the kernel doesn't and cannot have), 50 is what threaded
IRQs default too as well IIRC, so it would at least be consistent with
that.