Date: Wed, 3 Jan 2007 15:56:52 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: hackers@freebsd.org, "Anand H. Krishnan" <anandhkrishnan@gmail.com> Subject: Re: Doubts with scheduler code Message-ID: <200701031556.52960.jhb@freebsd.org> In-Reply-To: <9bf098930701020242t232a1131r355c693618169441@mail.gmail.com> References: <9bf098930701020242t232a1131r355c693618169441@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 02 January 2007 05:42, Anand H. Krishnan wrote: > Hi, > > I had a couple of doubts when I was going through 6.1 freebsd code. > > * First one is in the wakeup() code. After a series of calls wakeup() > lands in maybe_preempt() and if preemption is enabled maybe_preempt() > switches to a new thread (if a high priority thread has been made runnable). > That means that an interrupt handler which calls wakeup() will not return > immediately. (I'm looking @ ULE scheduler). > > So is there a problem when wakeup() is called from high priority (fast interr > upt) handlers ? Interrupt threads have higher priority than the threads they wakeup. For the INTR_FAST case we run INTR_FAST handlers inside a critical section so that if a INTR_FAST handler wakes up a thread such as the clock or serial SWI, the preemption is deferred until after the INTR_FAST handler returns. > * Second one is in spinlock code. Can anyone say why critical_enter is > called from spinlock_enter() ? The only thing that critical_enter seems to > be doing is to increment td_critnest which probably helps in finding out > whether a thread can be pre-empted or not. But spinlock_enter() disables > interrupts and I fail to understand how can any thread become runnable > and get scheduled in between. A thread may wake up another thread while holding a spin lock. There are numerous examples of this. > I've one more.. > > * msleep() allows a thread to change it's priority when it gets woken up and > in many places they gets woken up with very high priority indeed. Is there > any convincing reason as to why it should be ? This is something that the 4BSD scheduler has done since before FreeBSD existed. The priority boost is intended to give higher priority to interactive processes (since they tend to sleep on I/O a lot) versus compute-bound processes. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200701031556.52960.jhb>