Re: [PATCH v9 00/13] support "task_isolation" mode for nohz_full

[Mark Rutland]

Hi Chris,

Sorry for the delay. I had intended to take a look at this and so held
off replying, but my time has been taken up elsewhere.

On Wed, Jan 13, 2016 at 04:19:56PM -0500, Chris Metcalf wrote:
> On 01/13/2016 05:44 AM, Ingo Molnar wrote:
> >* Chris Metcalf <cmetcalf@xxxxxxxxxx> wrote:
> >
> >>(Adding Mark to cc's)
> >>
> >>On 01/12/2016 05:07 AM, Will Deacon wrote:
> >>>On Mon, Jan 11, 2016 at 04:15:50PM -0500, Chris Metcalf wrote:
> >>>>Ping!  There has been no substantive feedback to this version of
> >>>>the patch in the week since I posted it, which optimistically suggests
> >>>>to me that people may be satisfied with it.  If that's true, Frederic,
> >>>>I assume this would be pulled into your tree?
> >>>>
> >>>>I have slightly updated the v9 patch series since this posting:
> >>>>
> >>>>[...]
> >>>>
> >>>>- Incorporated Mark Rutland's changes to convert arm64
> >>>>   assembly to C code instead of using my own version.
> >>>Please avoid queuing these patches -- the first is already in the arm64
> >>>queue for 4.5 and the second was found to introduce a substantial
> >>>performance regression on the syscall entry/exit path. I think Mark had
> >>>an updated version to address that, so it would be easier not to have
> >>>an old version sitting in some other queue!
> >>I am not formally queueing them anywhere (like linux-next), though
> >>now that you mention it, that's a pretty good idea - I'll talk to Steven
> >>about that, assuming this merge window closes without the task
> >>isolation stuff going in.
> >NAK. Given the controversy, no way should this stuff go outside the primary trees
> >it affects: the scheduler, timer, irq, etc. trees.
> 
> Fair enough.  I'll plan to do v10 once the merge window closes.
> 
> Mark, let me know when/if you get a new version of the de-asm stuff
> for do_notify_resume() - thanks.

If I get the chance soon, I will do, though I suspect I won't have the
chance to give that the time it deserves over the next week or two. 

> Or, would it be helpful if I worked up the option I suggested, where
> we check the thread_info flags in the assembly code before calling out
> to the new loop in do_notify_resume()?

That would probably be for the best.

Thanks,
Mark.