Date: Fri, 17 Sep 2004 20:52:27 -0400 From: Stephan Uphoff <ups@tree.com> To: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: scheduler (sched_4bsd) questions Message-ID: <1095468747.31297.241.camel@palm.tree.com>
next in thread | raw e-mail | index | archive | help
Hi,
I finally found some time to take a peek at the sched_4bsd scheduler
and found two things I could not explain:
It looks like the thread priority of a thread in the kernel is normally
its user priority.
( Unless it slept with priority change or due to mutex priority
inheritance)
If this is true kernel threads can be preempted while holding
for example the root vnode lock (or other important kernel
resources) while not getting a chance to run until there are no more
user processes with better priority.
I am probably missing a priority adjustment on kernel entry somewhere
but seem to be unable to find it :-(
I am also stomped by the special case of adding a thread X with better
priority than the current thread to the runqueue if they belong to the
same ksegroup. In this case both kg_last_assigned and kg_avail_opennings
might be zero and setrunqueue() will not call sched_add().
Because of this it looks like the current thread will neither be
preempted not will TDF_NEEDRESCHED be set to force rescheduling at the
kernel boundary.
This situation should resolve itself at the next sched_switch - however
this might take a long time. (Especially if essential interrupt threads
are blocked by mutexes held by thread X)
Thanks in advance for any hints.
Stephan
PS: I am impressed how clean and easy to read the scheduler sources are.
Looks like a lot of hard work went into this.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1095468747.31297.241.camel>