[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200508113141.GB5298@hirez.programming.kicks-ass.net>
Date: Fri, 8 May 2020 13:31:41 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Quentin Perret <qperret@...gle.com>
Cc: Greg KH <gregkh@...uxfoundation.org>, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
bp@...en8.de, x86@...nel.org, hpa@...or.com, sudeep.holla@....com,
rafael@...nel.org, viresh.kumar@...aro.org, juri.lelli@...hat.com,
vincent.guittot@...aro.org, dietmar.eggemann@....com,
rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
mcgrof@...nel.org, keescook@...omium.org, yzaikin@...gle.com,
fweisbec@...il.com, tkjos@...gle.com, kernel-team@...roid.com
Subject: Re: [PATCH 00/14] Modularize schedutil
On Fri, May 08, 2020 at 12:16:12PM +0100, Quentin Perret wrote:
> However, the point I tried to make here is orthogonal to that. As of
> today using another governor than schedutil is fully supported upstream,
> and in fact it isn't even enabled by default for most archs. If vendors
> feel like using something else makes their product better, then I don't
> see why I need to argue with them about that. And frankly I don't see
> that support being removed from upstream any time soon.
Right, it'll take a while to get there. But that doesn't mean we
shouldn't encourage schedutil usage wherever and whenever possible. That
includes not making it easier to not use it.
In that respect making it modular goes against our ultimate goal (world
domination, <mad giggles here>).
Powered by blists - more mailing lists