[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170901072404.GA16446@kroah.com>
Date: Fri, 1 Sep 2017 09:24:04 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Martijn Coenen <maco@...roid.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Amit Pundir <amit.pundir@...aro.org>,
devel@...verdev.osuosl.org, Iliyan Malchev <malchev@...gle.com>,
LKML <linux-kernel@...r.kernel.org>,
Arve Hjønnevåg <arve@...roid.com>,
Martijn Coenen <maco@...gle.com>,
John Stultz <john.stultz@...aro.org>,
Colin Cross <ccross@...roid.com>,
Thomas Gleixner <tglx@...utronix.de>,
Christoph Hellwig <hch@....de>, Todd Kjos <tkjos@...gle.com>
Subject: Re: [PATCH v2 03/13] ANDROID: binder: add support for RT prio
inheritance.
On Thu, Aug 31, 2017 at 02:00:54PM +0200, Martijn Coenen wrote:
> On Thu, Aug 31, 2017 at 1:32 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> > AFAIK people are actively working on fixing that.
>
> SCHED_DEADLINE was definitely looked at in the past. We certainly
> don't use it on our own devices in Android Oreo, and I am not aware of
> any current plans to use it. But the Android org is big, so I may
> simply not be aware. In either case I'd be happy to support it if
> there is a need for it.
>
> >
> > I still have to look at the actual patches, but it all sounds very
> > dodgy. Probably won't have time until after LPC.
>
> Appreciate if you could take a look! In particular I'm curious why
> this approach is considered "dodgy", or "engineered sideways" as
> Thomas pointed out earlier. From what I can tell the reason why we
> want to change task priorities (potentially from a different task) is
> understood. So is the main concern using sched_setscheduler()
> directly, instead of having a prio "modifier" much like rt_mutex has?
> We (and our partners) are using these patches without issues, though
> it does come with the caveat that threads in the binder threadpool
> should not be changing their own priority from userspace for this to
> work correctly (though they shouldn't have been doing that before
> these patches either).
>
> Either way, it sounds like this discussion will take a bit longer, so
> I will pull out the few unrelated patches from this series and post
> them separately.
I've now applied patches 1, 2, 7, 9, 11, and 12 from this series to my
tree, so feel free to rebase on it for the next round of these patches.
thanks,
greg k-h
Powered by blists - more mailing lists