SW_PREEMPT and cpu runq

Murty, Ravi ravi.murty at intel.com
Thu May 8 23:02:08 UTC 2008

Oh, I find this happens only in ULE -- during sched_switch(), it sets
KEF_HOLD and then calls setrunqueue(). This ensures that the thread does
not migrate on preemptions.


-----Original Message-----
From: Murty, Ravi 
Sent: Thursday, May 08, 2008 3:48 PM
To: 'Julian Elischer'
Cc: freebsd-hackers at freebsd.org
Subject: RE: SW_PREEMPT and cpu runq

I guess two places.

1. maybe_preempt() - I've decided to preempt a thread on a cpu and the
outgoing thread is held (SW_PREEMPT) on the same cpu.
2. timer expires and thread is out of its slice (ULE), in this case I
remove the load and re-add it back to the same (current) cpu.

Sorry Julian, yes this is 6.2

Thanks much,

-----Original Message-----
From: Julian Elischer [mailto:julian at elischer.org] 
Sent: Thursday, May 08, 2008 3:28 PM
To: Murty, Ravi
Cc: freebsd-hackers at freebsd.org
Subject: Re: SW_PREEMPT and cpu runq

Murty, Ravi wrote:
> Hi,
> When a thread is being switched out and it is being preempted (e.g.
> quantum expires), why does sched_switch hold it on the current cpu?
> why does the code see that it was preempted and put it back on the
> queue?
> In other cases it looks to see if it can be migrated and the thread
> back some place else. If a thread is being kicked out and there is a
> perfectly idle CPU some where on the system, wouldn't it make sense to
> migrate the thread?

it shouldn't be held..
why do you think it is?
(and is this in 6.x still?)

> Thanks
> Ravi
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to
"freebsd-hackers-unsubscribe at freebsd.org"

More information about the freebsd-hackers mailing list