From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 12 13:11:55 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45B841065771; Wed, 12 Nov 2008 13:11:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C2A7B8FC1A; Wed, 12 Nov 2008 13:11:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mACDBNK8084446; Wed, 12 Nov 2008 08:11:48 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 11 Nov 2008 11:37:55 -0500 User-Agent: KMail/1.9.7 References: <6D5D25EA3941074EB7734E51B16687040AD02A77@orsmsx506.amr.corp.intel.com> In-Reply-To: <6D5D25EA3941074EB7734E51B16687040AD02A77@orsmsx506.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811111137.55731.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 12 Nov 2008 08:11:49 -0500 (EST) X-Virus-Scanned: ClamAV 0.93.1/8620/Wed Nov 12 04:05:38 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.0 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_12_24,NO_RELAYS autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: jeff@freebsd.org, "Murty, Ravi" Subject: Re: Typo in ULE in FreeBSD 8.0 -- that's not really a bug X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2008 13:11:55 -0000 On Monday 10 November 2008 12:57:44 pm Murty, Ravi wrote: > Hello All, > > I have been playing with ULE in 8.0 and while staring at tdq_notify noticed an interesting (and what seems like a typo) problem. > The intention of the function is obvious, send an IPI to notify the remote CPU of some new piece of work. In the case where there is no IPI currently pending on the target CPU and this thread should be preempting what's running there, the code checks in td (passed in as a parameter) is the IDLE thread (TDF_IDLETD). If so, it checks the state and sees if idle is RUNNING and if so figures it will notice this new work and we don't really need to send an expensive IPI. However, why would td (parameter) ever be the IDLE thread? It almost seems like this check will always fail and we end up sending a hard IPI to the target CPU which works, but may not be needed. May be we wanted to use PCPU->curthread instead of td? I think you are correct. Something like this might fix it: Index: sched_ule.c =================================================================== RCS file: /usr/cvs/src/sys/kern/sched_ule.c,v retrieving revision 1.246 diff -u -r1.246 sched_ule.c --- sched_ule.c 19 Jul 2008 05:13:47 -0000 1.246 +++ sched_ule.c 11 Nov 2008 16:36:25 -0000 @@ -942,7 +942,7 @@ static void tdq_notify(struct tdq *tdq, struct thread *td) { - int cpri; + struct thread *ctd; int pri; int cpu; @@ -950,10 +950,10 @@ return; cpu = td->td_sched->ts_cpu; pri = td->td_priority; - cpri = pcpu_find(cpu)->pc_curthread->td_priority; - if (!sched_shouldpreempt(pri, cpri, 1)) + ctd = pcpu_find(cpu)->pc_curthread; + if (!sched_shouldpreempt(pri, ctd->td_priority, 1)) return; - if (TD_IS_IDLETHREAD(td)) { + if (TD_IS_IDLETHREAD(ctd)) { /* * If the idle thread is still 'running' it's probably * waiting on us to release the tdq spinlock already. No -- John Baldwin