This only applies only to the idle thread and it says that the idle
thread actively monitors its need_resched flag and hence will
instantly call schedule() at that point. Hence there won't be any
delay either for IPI or for waiting to return from the kernel.
You might be right that the problem situation still arises, because
the idle_thread needs to content again for the lock.
Let me ask the otherway around, why do we HAVE to put it in ?
And if I missed something here, we put it outside the <if> clause.
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: [email protected]
(w) 914-945-2003 (fax) 914-945-4425 TL: 862-2003
Davide Libenzi <[email protected]>@lists.sourceforge.net on
07/17/2001 02:11:55 PM
Sent by: [email protected]
To: Hubertus Frnake <[email protected]>
cc: [email protected], [email protected],
[email protected]
Subject: Re: [Lse-tech] Re: CPU affinity & IPI latency (FIX)_
On 17-Jul-2001 Hubertus Frnake wrote:
> In an attempt to inline the code, somehow the tabs got lost. So here is
the
> attached correct patch fo 2.4.5. Please try and let me know whether you
> see your problems disappear and/or others arise.
> The sketchy writeup is still the same.
What is the reason You don't set the resched task in the fast path ?
best_cpu = p->processor;
if (can_schedule(p, best_cpu)) {
tsk = idle_task(best_cpu);
if ((cpu_curr(best_cpu) == tsk) &&
(cpu_resched(best_cpu) == NULL)) {
int need_resched;
send_now_idle:
/*
* If need_resched == -1 then we can skip sending
* the IPI altogether, tsk->need_resched is
* actively watched by the idle thread.
*/
need_resched = tsk->need_resched;
tsk->need_resched = 1;
if ((best_cpu != this_cpu) && !need_resched) {
>>>> cpu_resched(best_cpu) = p;
smp_send_reschedule(best_cpu);
}
return;
}
}
- Davide
_______________________________________________
Lse-tech mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/lse-tech
On 17-Jul-2001 Hubertus Franke wrote:
>
>
> This only applies only to the idle thread and it says that the idle
> thread actively monitors its need_resched flag and hence will
> instantly call schedule() at that point. Hence there won't be any
> delay either for IPI or for waiting to return from the kernel.
>
> You might be right that the problem situation still arises, because
> the idle_thread needs to content again for the lock.
> Let me ask the otherway around, why do we HAVE to put it in ?
> And if I missed something here, we put it outside the <if> clause.
Yep, we were talking about two different if-locations :)
Anyway, it's right, using the poll idle we've to change the position of the
assignment.
- Davide