On Wed, 24 Jan 2007, David Xu wrote:
Jeff Roberson wrote:
On Wed, 24 Jan 2007, David Xu wrote:
Jeff Roberson wrote:
if idlethread is preempted, who will clear its idle bit in
idle_cpus_mask ?
idle_cpus_mask was broken before for all schedulers. This commit didn't
change that. ULE doesn't use idle_cpus_mask and it's idlethread doesn't
set or clear it. The idle thread for the other schedulers remains
unchanged.
I havn't read ULE code, but 4BSD has following code:
This is the very same code that was there before. I didn't change it. I
just moved it into the schedulers. It was always broken with preemption. I
tried to use idle_cpus_mask in ULE but found that it always was set for
most CPUs. You will find that IPI_PREEMPT also had no effect but I fixed
that recently.
orignal code does not preempt per-cpu idle thread, so the idle threads
have chance to clear their idle bits in idle_cpu_masks, but now because
the threads can be preempted directly, so they don't have chance
to clear the masks, unless sched_switch clears them( but the code is not
there), without clearing them, very cpu will receive a broadcast IPI
whenever a thread is added to runqueue for 4BSD scheduler, this is
incorrect if a cpu is already running a non-idle thread.
The IPI_PREEMPT code was broken until I fixed it last week. It didn't
preempt any threads and it's not enabled by default in 4BSD. That and
maybe_preempt() are really the only pieces of code that would cause
preemption. I haven't changed maybe_preempt() but it allows for
preemption of the idlethread and has for as long as I'm aware.
I don't disagree that idle_cpu_mask is broken, however, I don't think my
commit had any effect on that or idlethread except within ULE. In my
opinion, the proper way to fix it is in sched_switch() anyhow. Julian
said he was going to look into that.
Cheers,
Jeff
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
