From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 11 21:00:51 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 9B7151065680 for ; Tue, 11 Nov 2008 21:00:51 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by mx1.freebsd.org (Postfix) with ESMTP id 6DC388FC0A for ; Tue, 11 Nov 2008 21:00:51 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by rv-out-0506.google.com with SMTP id g9so1108470rvb.3 for ; Tue, 11 Nov 2008 13:00:51 -0800 (PST) Received: by 10.141.49.6 with SMTP id b6mr4448063rvk.18.1226435902245; Tue, 11 Nov 2008 12:38:22 -0800 (PST) Received: from ?10.0.1.199? (cpe-66-91-191-118.hawaii.res.rr.com [66.91.191.118]) by mx.google.com with ESMTPS id k2sm26714975rvb.1.2008.11.11.12.38.19 (version=SSLv3 cipher=RC4-MD5); Tue, 11 Nov 2008 12:38:21 -0800 (PST) Date: Tue, 11 Nov 2008 10:37:24 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: "Murty, Ravi" In-Reply-To: <6D5D25EA3941074EB7734E51B16687040AD02A77@orsmsx506.amr.corp.intel.com> Message-ID: <20081111103600.G964@desktop> References: <6D5D25EA3941074EB7734E51B16687040AD02A77@orsmsx506.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 11 Nov 2008 22:12:17 +0000 Cc: "freebsd-hackers@freebsd.org" , jeff@FreeBSD.org, robert 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: Tue, 11 Nov 2008 21:00:51 -0000 On Mon, 10 Nov 2008, 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? Wow ravi, thanks. That's what it was at one point. It must've been refactored into brokenness. I'll fix and test soon. This has probably reduced the effectiveness of the mwait patch. Thanks, Jeff > > Thanks > Ravi > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >