On Tue, Aug 30, 2016 at 11:41:36AM -0400, Chris Metcalf wrote:
On 8/29/2016 8:55 PM, Frederic Weisbecker wrote:I think that making the code clearer on what needs to be done once for
On Mon, Aug 15, 2016 at 10:59:55AM -0400, Chris Metcalf wrote:That's true, but I really do like the idea of having a clean structure
On 8/11/2016 2:50 PM, Christoph Lameter wrote:Yes but we need to sort out what needs to be called only once on prctl().
On Thu, 11 Aug 2016, Frederic Weisbecker wrote:It's true that task_isolation_enter() is called every time before
Do we need to quiesce vmstat everytime before entering userspace?Once is sufficient after disabling the tick.
I thought that vmstat only need to be offlined once and for all?
returning to user space while task isolation is enabled.
But once we enter the kernel again after returning from the initial
prctl() -- assuming we are in NOSIG mode so doing so is legal in the
first place -- almost anything can happen, certainly including
restarting the tick. Thus, we have to make sure that normal quiescing
happens again before we return to userspace.
Once vmstat is quiesced, it's not going to need quiescing again even if we
restart the tick.
where we verify all our prerequisites in task_isolation_ready(), and
have code to try to get things fixed up in task_isolation_enter().
If we start moving some things here and some things there, it gets
harder to manage. I think by testing "!vmstat_idle()" in
task_isolation_enter() we are avoiding any substantial overhead.
all on prctl() and what needs to be done on all actual syscall return
is more important for readability.
I don't see how that helps. What will wake the thread up except a signal?See the other thread with Peter Z for the longer discussion of this.I don't think it helps either way. If reschedule is pending, the currentIt won't be better than spinning in a loop if there aren't any other+ if (!tick_nohz_tick_stopped())
+ set_tsk_need_resched(current);
Again, that won't help
schedulable processes, but it won't be worse either. If there is
another schedulable process, we at least will schedule it sooner than
if we just sat in a busy loop and waited for the scheduler to kick
us. But there's nothing else we can do anyway if we want to maintain
the guarantee that the dyn tick is stopped before return to userspace.
task already has TIF_RESCHED set.
At this point I'm leaning towards replacing the set_tsk_need_resched() with
set_current_state(TASK_INTERRUPTIBLE);
schedule();
__set_current_state(TASK_RUNNING);