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.
Ravi -----Original Message----- From: Murty, Ravi Sent: Thursday, May 08, 2008 3:48 PM To: 'Julian Elischer' Cc: freebsd-hackers@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, Ravi -----Original Message----- From: Julian Elischer [mailto:[EMAIL PROTECTED] Sent: Thursday, May 08, 2008 3:28 PM To: Murty, Ravi Cc: freebsd-hackers@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. time > quantum expires), why does sched_switch hold it on the current cpu? i.e. > why does the code see that it was preempted and put it back on the same > queue? > > In other cases it looks to see if it can be migrated and the thread goes > 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"