lkml.org 
[lkml]   [2014]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [tip:x86/asm] x86: Speed up ___preempt_schedule*() by using THUNK helpers
From
On Fri, Oct 3, 2014 at 4:26 PM, Oleg Nesterov <oleg@redhat.com> wrote:
>
> And I _think_ that preempt_schedule_context() should be fixed anyway,
> although I am not sure there is no something else. It does:
>
>
> preempt_disable_notrace();
> prev_ctx = exception_enter();
> preempt_enable_no_resched_notrace();
>
> preempt_schedule();
>
> preempt_disable_notrace();
> exception_exit(prev_ctx);
> preempt_enable_notrace();
>
> but exception_exit() is heavy, it is quite possible that TIF_NEED_RESCHED
> and thus set_preempt_need_resched() can be set again when we call
> preempt_enable_notrace(). And in this case preempt_schedule_context()
> will be called recursively.

Why the hell is it using "preempt_enable_notrace()" in the first
place? Shouldn't it use "preempt_enable_no_resched_notrace()", since
we do *not* want it to schedule, since the whole *point* is that any
scheduling should be called within "exception" context.

> Frederic, how about the patch below?

Why do it multiple times? The whole concept is fundamentally racy
anyway, in it doesn't guarantee that any *new* "need_resched()" would
be reacted to (since they could happen *after* the test), so there's
no point in trying to fix the "race", since it always remains at the
last iteration anyway. So adding the loop looks like just voodoo
programming, not actually fixing anything.

The real fix would appear to be to use
"preempt_enable_no_resched_notrace()", which your patch did, but
without the loop.

Yes?

Linus


\
 
 \ /
  Last update: 2014-10-04 02:41    [W:0.141 / U:0.764 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site