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: frankeh@us.ibm.com
(w) 914-945-2003 (fax) 914-945-4425 TL: 862-2003
Davide Libenzi <davidel@xmailserver.org>@lists.sourceforge.net on
07/17/2001 02:11:55 PM
Sent by: lse-tech-admin@lists.sourceforge.net
To: Hubertus Frnake <frankeh@watson.ibm.com>
cc: linux-kernel@vger.kernel.org, lse-tech@lists.sourceforge.net,
ak@suse.de
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
Lse-tech@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/lse-tech
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/