[RFC] Should we add Android's Interactive governor into mainline now?

[RFC] Should we add Android's Interactive governor into mainline now?

[Viresh Kumar]

Hi Rafael and others,

Since we have moved away from the background timers to scheduler
callbacks, should we consider merging the Interactive governor into
mainline ?

It was rejected earlier for few reasons, one of which was that we
didn't wanted to add on any new governors before the background
timers hack is removed and inputs received from scheduler.

I can try putting some effort to do that, but wanted to check what
others feel about it first.

Its getting used for mobile phones using Android for a very long
time now.

--
viresh

Re: [RFC] Should we add Android's Interactive governor into mainline now?

[Rafael J. Wysocki]

On Thu, May 12, 2016 at 4:04 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> Hi Rafael and others,

Hi,

> Since we have moved away from the background timers to scheduler
> callbacks, should we consider merging the Interactive governor into
> mainline ?

We may, depending on how it looks like. :-)

> It was rejected earlier for few reasons, one of which was that we
> didn't wanted to add on any new governors before the background
> timers hack is removed and inputs received from scheduler.

Actually, the last submission did not receive any comments from
anyone, so I'd call it lack of interest rather than rejection.

> I can try putting some effort to do that, but wanted to check what
> others feel about it first.
>
> Its getting used for mobile phones using Android for a very long
> time now.

I think that we'd be better off if the interactive governor was in the
tree, so if you have the time to work on it, that's great.

One caveat is that I have some governor API rearrangement in the works
and you'd need to rebase your work on top of that.  I've just sent two
patches, but there's more to come.

Re: [RFC] Should we add Android's Interactive governor into mainline now?

[Viresh Kumar]

On 12-05-16, 15:19, Rafael J. Wysocki wrote:
> Actually, the last submission did not receive any comments from
> anyone, so I'd call it lack of interest rather than rejection.

The last attempt had 70 patches in it :)

> I think that we'd be better off if the interactive governor was in the
> tree, so if you have the time to work on it, that's great.
> 
> One caveat is that I have some governor API rearrangement in the works
> and you'd need to rebase your work on top of that.  I've just sent two
> patches, but there's more to come.

That wouldn't be an issue and anyway I will take some time (I have to find some
first) to do that :)

-- 
viresh

Re: [RFC] Should we add Android's Interactive governor into mainline now?

[Rafael J. Wysocki]

On Fri, May 13, 2016 at 5:19 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 12-05-16, 15:19, Rafael J. Wysocki wrote:
>> Actually, the last submission did not receive any comments from
>> anyone, so I'd call it lack of interest rather than rejection.
>
> The last attempt had 70 patches in it :)

Just for the record, this was the last attempt:
https://patchwork.kernel.org/patch/7514441/

Re: [RFC] Should we add Android's Interactive governor into mainline now?

[Viresh Kumar]

On 13-05-16, 13:06, Rafael J. Wysocki wrote:
> On Fri, May 13, 2016 at 5:19 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > On 12-05-16, 15:19, Rafael J. Wysocki wrote:
> >> Actually, the last submission did not receive any comments from
> >> anyone, so I'd call it lack of interest rather than rejection.
> >
> > The last attempt had 70 patches in it :)
> 
> Just for the record, this was the last attempt:
> https://patchwork.kernel.org/patch/7514441/

Yeah, he sent a single patch as well (which failed to build). But
yeah, I was talking about his attempts only :)

-- 
viresh

Re: [RFC] Should we add Android's Interactive governor into mainline now?

[Steve Muckle]

On Thu, May 12, 2016 at 07:34:01AM +0530, Viresh Kumar wrote:
> Since we have moved away from the background timers to scheduler
> callbacks, should we consider merging the Interactive governor into
> mainline ?

Merging interactive will help us more easily compare schedutil against
it and get schedutil at or beyond feature parity.

That said my understanding is that the goal is to eventually deprecate
the non-sched governors. That will be made harder by adding another one
into the tree.

Re: [RFC] Should we add Android's Interactive governor into mainline now?

[Rafael J. Wysocki]

On Thu, May 12, 2016 at 6:36 PM, Steve Muckle <steve.muckle@linaro.org> wrote:
> On Thu, May 12, 2016 at 07:34:01AM +0530, Viresh Kumar wrote:
>> Since we have moved away from the background timers to scheduler
>> callbacks, should we consider merging the Interactive governor into
>> mainline ?
>
> Merging interactive will help us more easily compare schedutil against
> it and get schedutil at or beyond feature parity.

Exactly.

> That said my understanding is that the goal is to eventually deprecate
> the non-sched governors. That will be made harder by adding another one
> into the tree.

We can't really deprecate any out-of-the-tree code, because it is
beyond the scope of our influence, so one can argue that taking it
into the tree may actually allow us to deprecate it at one point going
forward. :-)

Seriously, though, "deprecation" may not be the right term to use
here.  Our goal, IMO, should be to persuade the users of the code in
question to switch over to something else and I'm not really sure if
refusing to take that code into the tree is the best way to achieve
that goal.

I do believe that if there's a significant piece of code living out of
the tree for a sufficiently long time, the tree is likely to be
missing something important.  Then, it is really difficult to figure
out what is missing without even trying to take that code into the
tree.

Re: [RFC] Should we add Android's Interactive governor into mainline now?

[Steve Muckle]

On Thu, May 12, 2016 at 10:34:39PM +0200, Rafael J. Wysocki wrote:
> > That said my understanding is that the goal is to eventually deprecate
> > the non-sched governors. That will be made harder by adding another one
> > into the tree.
> 
> We can't really deprecate any out-of-the-tree code, because it is
> beyond the scope of our influence, so one can argue that taking it
> into the tree may actually allow us to deprecate it at one point going
> forward. :-)
> 
> Seriously, though, "deprecation" may not be the right term to use
> here.  Our goal, IMO, should be to persuade the users of the code in
> question to switch over to something else and I'm not really sure if
> refusing to take that code into the tree is the best way to achieve
> that goal.
> 
> I do believe that if there's a significant piece of code living out of
> the tree for a sufficiently long time, the tree is likely to be
> missing something important.  Then, it is really difficult to figure
> out what is missing without even trying to take that code into the
> tree.

By far the biggest user of interactive is Android (I'm not aware of its
use elsewhere). Persuading Google to switch is relatively doable once a
viable alternative exists. After that point I'd expect the desire to
merge and maintain interactive would almost immediately disappear. Folks
wanting to run upstream kernels on already released devices have much
bigger hurdles than merging the interactive governor.

But if interactive is merged I'm worried that many other users on random
platforms will adopt it, for whatever reason, introducing a support
burden during a time that we're trying to develop and encourage an
alternative.

Anyway that's just my $.02 - it'd actually be good for me as
again it'd permit easier comparison with schedutil, so I won't complain
if it goes in :) .

Re: [RFC] Should we add Android's Interactive governor into mainline now?

[Viresh Kumar]

On 12-05-16, 14:10, Steve Muckle wrote:
> By far the biggest user of interactive is Android (I'm not aware of its
> use elsewhere). Persuading Google to switch is relatively doable once a
> viable alternative exists. After that point I'd expect the desire to
> merge and maintain interactive would almost immediately disappear. Folks
> wanting to run upstream kernels on already released devices have much
> bigger hurdles than merging the interactive governor.
> 
> But if interactive is merged I'm worried that many other users on random
> platforms will adopt it, for whatever reason, introducing a support
> burden during a time that we're trying to develop and encourage an
> alternative.

Lets assume that its going to take enough time for (specially) Android to start
using the schedutil governor. That's how it works.

So, if we are worried about new users using it (who may not have a good reason
to do that but did it by mistake), maybe we can make the interactive governor
depend on CONFIG_ARM.

> Anyway that's just my $.02 - it'd actually be good for me as
> again it'd permit easier comparison with schedutil, so I won't complain
> if it goes in :) .

-- 
viresh

Re: [RFC] Should we add Android's Interactive governor into mainline now?

[Steve Muckle]

On Fri, May 13, 2016 at 08:51:56AM +0530, Viresh Kumar wrote:
> On 12-05-16, 14:10, Steve Muckle wrote:
> > By far the biggest user of interactive is Android (I'm not aware of its
> > use elsewhere). Persuading Google to switch is relatively doable once a
> > viable alternative exists. After that point I'd expect the desire to
> > merge and maintain interactive would almost immediately disappear. Folks
> > wanting to run upstream kernels on already released devices have much
> > bigger hurdles than merging the interactive governor.
> > 
> > But if interactive is merged I'm worried that many other users on random
> > platforms will adopt it, for whatever reason, introducing a support
> > burden during a time that we're trying to develop and encourage an
> > alternative.
> 
> Lets assume that its going to take enough time for (specially) Android to start
> using the schedutil governor. That's how it works.

Perhaps I'm more optimistic about schedutil's swift adoption by Google
once it's reached feature parity with interactive.

> So, if we are worried about new users using it (who may not have a good reason
> to do that but did it by mistake), maybe we can make the interactive governor
> depend on CONFIG_ARM.

Is there precedent for putting in artificial dependencies (i.e. ones
with no real runtime technical justification) for this kind of purpose,
i.e. to limit who starts using a merged feature? It seems a bit messy to me.

Re: [RFC] Should we add Android's Interactive governor into mainline now?

[Viresh Kumar]

On 12-05-16, 23:14, Steve Muckle wrote:
> Is there precedent for putting in artificial dependencies (i.e. ones
> with no real runtime technical justification) for this kind of purpose,
> i.e. to limit who starts using a merged feature? It seems a bit messy to me.

I am against doing that as well. It was just an option if we want to
*force* people to not use it :)

I think we better leave it to individuals to choose what they want (we
can't control that anyway) and lets include interactive.

Will do some work on that soon.

-- 
viresh

Re: [RFC] Should we add Android's Interactive governor into mainline now?

[Juri Lelli]

Hi,

On 12/05/16 14:10, Steve Muckle wrote:
> On Thu, May 12, 2016 at 10:34:39PM +0200, Rafael J. Wysocki wrote:
> > > That said my understanding is that the goal is to eventually deprecate
> > > the non-sched governors. That will be made harder by adding another one
> > > into the tree.
> > 
> > We can't really deprecate any out-of-the-tree code, because it is
> > beyond the scope of our influence, so one can argue that taking it
> > into the tree may actually allow us to deprecate it at one point going
> > forward. :-)
> > 
> > Seriously, though, "deprecation" may not be the right term to use
> > here.  Our goal, IMO, should be to persuade the users of the code in
> > question to switch over to something else and I'm not really sure if
> > refusing to take that code into the tree is the best way to achieve
> > that goal.
> > 
> > I do believe that if there's a significant piece of code living out of
> > the tree for a sufficiently long time, the tree is likely to be
> > missing something important.  Then, it is really difficult to figure
> > out what is missing without even trying to take that code into the
> > tree.
> 
> By far the biggest user of interactive is Android (I'm not aware of its
> use elsewhere). Persuading Google to switch is relatively doable once a
> viable alternative exists. After that point I'd expect the desire to
> merge and maintain interactive would almost immediately disappear. Folks
> wanting to run upstream kernels on already released devices have much
> bigger hurdles than merging the interactive governor.
> 
> But if interactive is merged I'm worried that many other users on random
> platforms will adopt it, for whatever reason, introducing a support
> burden during a time that we're trying to develop and encourage an
> alternative.
> 

Right. It looks a bit odd to merge (and then maintain) something while
we are actively working on an alternative designed to suit the same kind
of needs.  Also considering that, with Viresh's effort, the merge
request will not come from the original authors.

> Anyway that's just my $.02 - it'd actually be good for me as
> again it'd permit easier comparison with schedutil, so I won't complain
> if it goes in :) .
> 

Anyway, I can't say that comparison would not be much easier. :-)
Even though we won't run the workloads interactive has been designed for
on mainline, I guess.

Best,

- Juri

Re: [RFC] Should we add Android's Interactive governor into mainline now?

[Rafael J. Wysocki]

On Fri, May 13, 2016 at 1:44 PM, Juri Lelli <juri.lelli@arm.com> wrote:
> Hi,
>
> On 12/05/16 14:10, Steve Muckle wrote:
>> On Thu, May 12, 2016 at 10:34:39PM +0200, Rafael J. Wysocki wrote:
>> > > That said my understanding is that the goal is to eventually deprecate
>> > > the non-sched governors. That will be made harder by adding another one
>> > > into the tree.
>> >
>> > We can't really deprecate any out-of-the-tree code, because it is
>> > beyond the scope of our influence, so one can argue that taking it
>> > into the tree may actually allow us to deprecate it at one point going
>> > forward. :-)
>> >
>> > Seriously, though, "deprecation" may not be the right term to use
>> > here.  Our goal, IMO, should be to persuade the users of the code in
>> > question to switch over to something else and I'm not really sure if
>> > refusing to take that code into the tree is the best way to achieve
>> > that goal.
>> >
>> > I do believe that if there's a significant piece of code living out of
>> > the tree for a sufficiently long time, the tree is likely to be
>> > missing something important.  Then, it is really difficult to figure
>> > out what is missing without even trying to take that code into the
>> > tree.
>>
>> By far the biggest user of interactive is Android (I'm not aware of its
>> use elsewhere). Persuading Google to switch is relatively doable once a
>> viable alternative exists. After that point I'd expect the desire to
>> merge and maintain interactive would almost immediately disappear. Folks
>> wanting to run upstream kernels on already released devices have much
>> bigger hurdles than merging the interactive governor.
>>
>> But if interactive is merged I'm worried that many other users on random
>> platforms will adopt it, for whatever reason, introducing a support
>> burden during a time that we're trying to develop and encourage an
>> alternative.
>>
>
> Right. It looks a bit odd to merge (and then maintain) something while
> we are actively working on an alternative designed to suit the same kind
> of needs.

I'm not worried too much about the maintenance part.  The code seems
to be mostly self-contained and it shouldn't add too many additional
constraints on the core as far as the interface is concerned.

> Also considering that, with Viresh's effort, the merge
> request will not come from the original authors.

Which may not be a bad thing. ;-)

>> Anyway that's just my $.02 - it'd actually be good for me as
>> again it'd permit easier comparison with schedutil, so I won't complain
>> if it goes in :) .
>>
>
> Anyway, I can't say that comparison would not be much easier. :-)
> Even though we won't run the workloads interactive has been designed for
> on mainline, I guess.

Think about running Android on top of the mainline, though.  That
would be somewhat easier if we had interactive in the mainline,
wouldn't it?

Re: [RFC] Should we add Android's Interactive governor into mainline now?

[Juri Lelli]

On 13/05/16 13:56, Rafael J. Wysocki wrote:
> On Fri, May 13, 2016 at 1:44 PM, Juri Lelli <juri.lelli@arm.com> wrote:
> > Hi,
> >
> > On 12/05/16 14:10, Steve Muckle wrote:
> >> On Thu, May 12, 2016 at 10:34:39PM +0200, Rafael J. Wysocki wrote:
> >> > > That said my understanding is that the goal is to eventually deprecate
> >> > > the non-sched governors. That will be made harder by adding another one
> >> > > into the tree.
> >> >
> >> > We can't really deprecate any out-of-the-tree code, because it is
> >> > beyond the scope of our influence, so one can argue that taking it
> >> > into the tree may actually allow us to deprecate it at one point going
> >> > forward. :-)
> >> >
> >> > Seriously, though, "deprecation" may not be the right term to use
> >> > here.  Our goal, IMO, should be to persuade the users of the code in
> >> > question to switch over to something else and I'm not really sure if
> >> > refusing to take that code into the tree is the best way to achieve
> >> > that goal.
> >> >
> >> > I do believe that if there's a significant piece of code living out of
> >> > the tree for a sufficiently long time, the tree is likely to be
> >> > missing something important.  Then, it is really difficult to figure
> >> > out what is missing without even trying to take that code into the
> >> > tree.
> >>
> >> By far the biggest user of interactive is Android (I'm not aware of its
> >> use elsewhere). Persuading Google to switch is relatively doable once a
> >> viable alternative exists. After that point I'd expect the desire to
> >> merge and maintain interactive would almost immediately disappear. Folks
> >> wanting to run upstream kernels on already released devices have much
> >> bigger hurdles than merging the interactive governor.
> >>
> >> But if interactive is merged I'm worried that many other users on random
> >> platforms will adopt it, for whatever reason, introducing a support
> >> burden during a time that we're trying to develop and encourage an
> >> alternative.
> >>
> >
> > Right. It looks a bit odd to merge (and then maintain) something while
> > we are actively working on an alternative designed to suit the same kind
> > of needs.
> 
> I'm not worried too much about the maintenance part.  The code seems
> to be mostly self-contained and it shouldn't add too many additional
> constraints on the core as far as the interface is concerned.
> 

Yeah, this is true.

> > Also considering that, with Viresh's effort, the merge
> > request will not come from the original authors.
> 
> Which may not be a bad thing. ;-)
> 

:-)

> >> Anyway that's just my $.02 - it'd actually be good for me as
> >> again it'd permit easier comparison with schedutil, so I won't complain
> >> if it goes in :) .
> >>
> >
> > Anyway, I can't say that comparison would not be much easier. :-)
> > Even though we won't run the workloads interactive has been designed for
> > on mainline, I guess.
> 
> Think about running Android on top of the mainline, though.  That
> would be somewhat easier if we had interactive in the mainline,
> wouldn't it?
> 

I agree that there might be value in reducing the gap between Android
and mainline (even though I still fear that lacking interactive is not
the biggest problem out there). However, wouldn't it be better if we
convince Google folks to switch to something coming from mainline
instead of doing the other way around?

Anyway, as said, if Viresh wants and has time to work on this I think it
will still help doing comparisons, so I'm not saying no to it! :-)

Best,

- Juri