Date: Wed, 29 Dec 2010 08:43:52 -0500 From: John Baldwin <jhb@freebsd.org> To: David Xu <davidxu@freebsd.org> Cc: arch@freebsd.org, Julian Elischer <julian@elischer.org> Subject: Re: TDF_NEEDRESCHED (was: Realtime thread priorities) Message-ID: <201012290843.52677.jhb@freebsd.org> In-Reply-To: <4D1AEFC0.7030400@freebsd.org> References: <4D1AEFC0.7030400@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, December 29, 2010 3:22:24 am David Xu wrote: > Hi all, > > I think flag TDF_NEEDRESCHED should not be cleared by sched_switch() in > ULE or 4BSD, instead it should only be cleared by ast() in subr_trap.c. > The reason is that the flag indicates thread should reset its priority > and switch context at user boundary because its user mode priority is > lowered or there is higher priority thread wants to run. > Kernel needs to use this flag to reset its priority to td_user_pri > before a thread returns to user mode, in current code, if an interrupt > thread preempts a user thread, sched_switch() clears the flag for > preempted thread and then switches to preempting thread, this causes > preempted thread to forget resetting its current priority to td_user_pri > this becauses assemble language code doreti() can not find the flag, > and ast() is not called, the thread ends up running user mode code > at very high level priority. Fix me, if I am wrong. Hmm, I think you are correct in which case I broke this many years ago. :( I think it might have worked originally because TDF_NEEDRESCHED triggered the preemption itself in ast(). The bug was probably introduced when I moved preemption into setrunqueue() itself (now sched_add() / critical_exit()). I think originally we also set TDF_NEEDRESCHED more often than we needed to, but now we probably don't (though we should check that it is now only set when we need to run that particular bit of code in ast() and nowhere else). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201012290843.52677.jhb>