Date: Thu, 4 Jan 2007 09:29:14 +0530 From: "Anand H. Krishnan" <anandhkrishnan@gmail.com> To: "John Baldwin" <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: Doubts with scheduler code Message-ID: <9bf098930701031959o3956bdfw7628cf1a5ef5b698@mail.gmail.com> In-Reply-To: <200701031556.52960.jhb@freebsd.org> References: <9bf098930701020242t232a1131r355c693618169441@mail.gmail.com> <200701031556.52960.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > > * 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. Saw that yesterday. Thanks for the clarification... > > > * 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. Never thought about that.. > > > 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. Thanks John and Coleman for your replies. Anand > > -- > John Baldwin >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9bf098930701031959o3956bdfw7628cf1a5ef5b698>