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

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:

quoted

* Chris Metcalf [off-list ref] wrote:

quoted

(Adding Mark to cc's)

On 01/12/2016 05:07 AM, Will Deacon wrote:

quoted

On Mon, Jan 11, 2016 at 04:15:50PM -0500, Chris Metcalf wrote:

quoted

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.