From owner-freebsd-arch Wed Jan 29 16:40:34 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC76737B401 for ; Wed, 29 Jan 2003 16:40:32 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DC2743F3F for ; Wed, 29 Jan 2003 16:40:32 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0U0eM0i070156; Wed, 29 Jan 2003 16:40:22 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0U0eJQe070153; Wed, 29 Jan 2003 16:40:19 -0800 (PST) Date: Wed, 29 Jan 2003 16:40:19 -0800 (PST) From: Matthew Dillon Message-Id: <200301300040.h0U0eJQe070153@apollo.backplane.com> To: Jeff Roberson Cc: Kris Kennaway , Julian Elischer , Subject: Found another SCHED_ULE bug. References: <20030129041155.Y31308-100000@mail.chesapeake.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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