From owner-freebsd-performance@FreeBSD.ORG Sun Sep 16 15:46:00 2007 Return-Path: Delivered-To: performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2A9A16A41B; Sun, 16 Sep 2007 15:46:00 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 81AFE13C45A; Sun, 16 Sep 2007 15:46:00 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.1/8.14.1/NETPLEX) with ESMTP id l8GFjwwv022327; Sun, 16 Sep 2007 11:45:59 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.netplex.net [204.213.176.10]); Sun, 16 Sep 2007 11:45:59 -0400 (EDT) Date: Sun, 16 Sep 2007 11:45:58 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kip Macy In-Reply-To: Message-ID: References: <46EC1B55.4060202@FreeBSD.org> <200709152250.50879.kurt@intricatesoftware.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: java@freebsd.org, Kris Kennaway , freebsd-java@freebsd.org, performance@freebsd.org, Kurt Miller Subject: Re: Massive performance loss from OS::sleep hack X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 15:46:00 -0000 On Sat, 15 Sep 2007, Kip Macy wrote: > Or more likely they'll continue to maintain a sched_yield that isn't > posix compliant. We may just want to add some sort of interface so the > jvm can tell the kernel that sched_yield should be non-compliant for > the current process. I don't think that is a good idea, it seems like too much of a hack. The scheduler(s) should schedule threads the way they are designed to, either obeying a threads priority, using it as a hint, or totally ignoring it. If the JVM kept track of the thread priorities in use, I suppose Thread.yield() could first lower the current thread's priority to the next used priority and then yield, raising the priority back after the yield. This isn't perfect, there are race conditions, the next highest priority thread(s) could be blocked and not runnable, etc. Maybe just lowering the priority to min or default priority would work well enough. This test would fail even on Solaris if you use SCHED_RR or SCHED_FIFO since it is POSIX compliant for those scheduling classes. -- DE