Date: Wed, 29 Jan 2003 16:40:19 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Jeff Roberson <jroberson@chesapeake.net> Cc: Kris Kennaway <kris@obsecurity.org>, Julian Elischer <julian@elischer.org>, <arch@FreeBSD.ORG> Subject: Found another SCHED_ULE bug. Message-ID: <200301300040.h0U0eJQe070153@apollo.backplane.com> References: <20030129041155.Y31308-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I believe I found another bug. While checking interrupt
latencies (using ping from another machine), I noticed that
cpu-bound processes could cause large ping latencies.
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.
The result is the target cpu runs through its time slice
before scheduling the new thread, causing interrupt
latency.
This isn't a problem in sched_4bsd because the run queue is
consolidated, so setting NEEDRESCHED on any cpu's curthread
is sufficient to get cpu to the new (interrupt) thread.
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.
-Matt
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?200301300040.h0U0eJQe070153>