Even more importantly, we rely onThis just seems like a mis-design. We don't know why the scheduler
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.
tick is on, so we're just going to reschedule until the problem goes
Your patches more or less implement "don't run me unless I'mBTW, 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.
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.