Date: Wed, 29 Jan 2003 20:09:05 -0500 (EST) From: Jeff Roberson <jroberson@chesapeake.net> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Kris Kennaway <kris@obsecurity.org>, Julian Elischer <julian@elischer.org>, <arch@FreeBSD.ORG> Subject: Re: Found another SCHED_ULE bug. Message-ID: <20030129200528.Y31308-100000@mail.chesapeake.net> In-Reply-To: <200301300040.h0U0eJQe070153@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 29 Jan 2003, Matthew Dillon wrote: > I think the problem has to do with how KEF_NEEDRESCHED is > set in sched_wakeup(). Specifically, in sched_wakeup() > you only set KEF_NEEDRESCHED on curthread, missing the fact > that the KSE may have been added to a different cpu's queue. > Setting KEF_NEEDRESCHED on curthread for the current cpu will > not necessarily reschedule the thread being woken up on the > target cpu. It looks like this isn't terribly important for anything other than interrupt handlers or maybe 'real-time' threads. The solution for interrupt handlers is simple. If we can preempt we can force it to run on the cpu that the interrupt fired on. I have this in my local tree but it needs to be implemented in a more general way. I will produce a patch in the next few days. If we want to solve it for things other than interrupt handlers we'll have to peak at the currently executing thread on the cpu that we're inserting the thread onto. This is sort of gross. > > I'm not sure how to solve the problem in ULE. I tried calling > forward_signal() on the target cpu's curthread, but it > panic'd with 'thread not TDS_RUNNING' or something like that. > You may have to force the interrupt thread to be scheduled on > the current cpu in order to properly reschedule it. Thanks for the bug report! Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030129200528.Y31308-100000>