lkml.org 
[lkml]   [2015]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@arm.com


\
 
 \ /
  Last update: 2015-09-15 16:01    [W:0.120 / U:0.576 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site