Re: Ping: [PATCH v15 00/13] support "task_isolation" mode
From: Frederic Weisbecker
Date: Tue Sep 27 2016 - 10:35:43 EST
On Mon, Aug 29, 2016 at 12:27:06PM -0400, Chris Metcalf wrote:
> On 8/16/2016 5:19 PM, Chris Metcalf wrote:
> >Here is a respin of the task-isolation patch set.
> >
> >Again, I have been getting email asking me when and where this patch
> >will be upstreamed so folks can start using it. I had been thinking
> >the obvious path was via Frederic Weisbecker to Ingo as a NOHZ kind of
> >thing. But perhaps it touches enough other subsystems that that
> >doesn't really make sense? Andrew, would it make sense to take it
> >directly via your tree? Frederic, Ingo, what do you think?
>
> Ping!
>
> No concerns have been raised yet with the v15 version of the patch series
> in the two weeks since I posted it, and I think I have addressed all
> previously-raised concerns (or perhaps people have just given up arguing
> with me).
>
> I did add Catalin's Reviewed-by to 08/13 (thanks!) and updated my
> kernel.org repo.
>
> Does this feel like something we can merge when the 4.9 merge window opens?
> If so, whose tree is best suited for it? Or should I ask Stephen to put it into
> linux-next now and then ask Linus to merge it directly? I recall Ingo thought
> this was a bad idea when I suggested it back in January, but I'm not sure where
> we got to in terms of a better approach.
As it seems we are still debating a lot of things in this patchset that has already
reached v15, I think you should split it in smaller steps in order to move forward
and only get into the next step once the previous is merged.
You could start with a first batch that introduces the prctl() and does the best effort
one-shot isolation part. Which means the actions that only need to be performed once
on the prctl call.
Once we get that merged we can focus on what needs to be performed on every return
to userspace if that's really needed. Including possibly waiting on some completion.
Then once we rip out the residual 1hz we can start to think about signal the user
on any interruption, etc...
Does that sound feasible to you?
Thanks.