[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150915134556.GD16853@twins.programming.kicks-ass.net>
Date: Tue, 15 Sep 2015 15:45:56 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Juri Lelli <juri.lelli@....com>
Cc: "mturquette@...libre.com" <mturquette@...libre.com>,
"mingo@...hat.com" <mingo@...hat.com>,
"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
"daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>,
Dietmar Eggemann <Dietmar.Eggemann@....com>,
"yuyang.du@...el.com" <yuyang.du@...el.com>,
"rjw@...ysocki.net" <rjw@...ysocki.net>,
"sgurrappadi@...dia.com" <sgurrappadi@...dia.com>,
"pang.xunlei@....com.cn" <pang.xunlei@....com.cn>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: Re: [RFCv5 PATCH 38/46] sched: scheduler-driven cpu frequency
selection
On Mon, Sep 14, 2015 at 04:57:35PM +0100, Juri Lelli wrote:
> On 04/09/15 14:27, Juri Lelli wrote:
> > So, just to recall what we discussed at LPC (I have Mike's slides
> > at hand :-)). It seems that key points are:
> >
> > 1- we agreed that locking in cpufreq core has to change as we
> > have to access it from scheduler hot-paths; what Peter is
> > proposing above looks viable to me, what others (way more
> > confident then me with cpufreq inners) say?
Rafael had some thoughts IIRC.
> > 2- the interface has to be extended as we have to let other
> > scheduling classes drive freq selection too; I guess that how
> > we do aggregation depends on the nature of sched classes,
> > but we didn't really reach any sort of agreement here; is
> > this anyway something we can focus on after fixing locking?
Right, that's going to be interesting. Reading through that SchedTune
thread has been educational (I really had no clue what it was on about
on initial reading, the discussion that's on-going clarified a lot).
It seems that even the fair class might want to provide minimal hints
due to that 'boost' / 'interactive' nonsense.
> > 3- the interface should also support peripheral devices; this
> > seems a interesting feature to have, but how about we postpone
> > it after we've got previous points right?
Agreed, that's a can of worms :-) Better start with the 'simple' things.
That said; ISTR a patch set on this topic recently.
lkml.kernel.org/r/1441904972-5809-1-git-send-email-javi.merino@....com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists