On 10/20/2015 05:26 PM, Andy Lutomirski wrote:
Even more importantly, we rely on
rescheduling to take care of the fact that the scheduler tick may still
be running, and therefore loop back to the schedule() call that's run
when TIF_NEED_RESCHED gets set.
This just seems like a mis-design. We don't know why the scheduler
tick is on, so we're just going to reschedule until the problem goes
away?
See my previous email about polite vs aggressive design for more
thoughts on this, but, yes. I'm not sure there's a way to do anything
else, other than my proposal there to dig deep into the scheduler
and allow it to switch to idle for a few tasks - but again, I'm just
not sure the complexity is worth the runtime power savings.
BTW, should isolation just be a scheduler class (SCHED_ISOLATED)?
So a scheduler class is an interesting idea certainly, although not
one I know immediately how to implement. I'm not sure whether
it makes sense to require a user be root or have a suitable rtprio
rlimit, but perhaps so. The nice thing about the current patch
series is that you can affinitize yourself to a nohz_full core and
declare that you want to run task-isolated, and none of that
requires root nor really is there a reason it should.
Your patches more or less implement "don't run me unless I'm
isolated". A scheduler class would be more like "isolate me (and
maybe make me super high priority so it actually happens)".
I'm not a scheduler person, so I don't know. But "don't run me unless
I'm isolated" seems like a design that will, at best, only ever work
by dumb luck. You have to disable migration, avoid other runnable
tasks, hope that the kernel keeps working the way it did when you
wrote the patch, hope you continue to get lucky enough that you ever
get to user mode in the first place, etc.
Could you explain the "dumb luck" characterization a bit more?
You're definitely right that I need to test for isolcpus separately
now that it's been decoupled from nohz_full again, so I will
add that to the next release of the series.
But the rest of it seems like things you just control for when you
are running the application, and if you do it right, the
application runs. If you don't (e.g. you intentionally schedule
multiple processes on the same core), the app doesn't run,
and you fix it in development.
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
