From owner-freebsd-java@FreeBSD.ORG Tue Sep 18 17:28:51 2007 Return-Path: Delivered-To: freebsd-java@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FF9116A420; Tue, 18 Sep 2007 17:28:51 +0000 (UTC) (envelope-from kurt@intricatesoftware.com) Received: from mail1.intricatesoftware.com (cl-18.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:11::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3F55613C47E; Tue, 18 Sep 2007 17:28:51 +0000 (UTC) (envelope-from kurt@intricatesoftware.com) Received: from seraph.intricatesoftware.com (relay@localhost.intricatesoftware.com [IPv6:::1]) by mail1.intricatesoftware.com (8.14.1/8.13.4) with ESMTP id l8IHSl8W030755; Tue, 18 Sep 2007 13:28:48 -0400 (EDT) Received: from seraph.intricatesoftware.com (truk@localhost.intricatesoftware.com [127.0.0.1]) by seraph.intricatesoftware.com (8.14.1/8.14.1) with ESMTP id l8IHSlY3029218; Tue, 18 Sep 2007 13:28:48 -0400 (EDT) Message-ID: <46F00ACF.1080700@intricatesoftware.com> Date: Tue, 18 Sep 2007 13:28:47 -0400 From: Kurt Miller User-Agent: Thunderbird 2.0.0.5 (X11/20070804) MIME-Version: 1.0 To: Daniel Eischen References: <46EC1B55.4060202@FreeBSD.org> <46EDDCC9.90403@intricatesoftware.com> <200709180721.48995.kurt@intricatesoftware.com> <46EFDDA8.2030603@intricatesoftware.com> In-Reply-To: X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SMTP-Vilter-Version: 1.3.6 X-SMTP-Vilter-Virus-Backend: clamd X-SMTP-Vilter-Status: clean X-SMTP-Vilter-clamd-Virus-Status: clean X-Spamd-Symbols: ALL_TRUSTED X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Score: -1.4 X-Spam-Threshold: 5.0 X-Spam-Probability: -0.3 X-Its-A-Nuisance: This is spam X-SMTP-Vilter-Unwanted-Backend: attachment X-SMTP-Vilter-attachment-Unwanted-Status: clean Cc: Kip Macy , Kris Kennaway , performance@freebsd.org, freebsd-java@freebsd.org Subject: Re: Massive performance loss from OS::sleep hack X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 17:28:51 -0000 Daniel Eischen wrote: > On Tue, 18 Sep 2007, Kurt Miller wrote: > >> Hi Daniel, >> >> Daniel Eischen wrote: >>> On Tue, 18 Sep 2007, Kurt Miller wrote: >>> >>>> David Xu confirmed for me that pthread_yield() does give some >>>> time to lower priority threads on 7.0 using thr. Attached and inline >>>> are two patches for the 1.5 port that is how I suggest the issue be >>>> addressed. >>> >>> I don't think you should rely on pthread_yield() doing that, >>> it is dependent on the scheduler, and if you are running >>> in SCHED_FIFO/SCHED_RR, it won't work with libthr either. >>> Currently, you can only run in SCHED_FIFO or SCHED_RR as >>> root using libthr, but that hopefully won't always be >>> true. >> >> Shoot I forgot to mention a few things in my last email... >> The c test program I resurrected from 18 months ago had >> >> pthread_attr_setschedpolicy(&attr, SCHED_FIFO); >> >> in it. The jdk doesn't set the schedpolicy it uses the >> default one. That line was left over from my testing >> different policies under kse to see if I could work- >> around the problem. Since the jdk doesn't set the policy, >> I believe we don't need to be concerned with SCHED_FIFO >> and SCHED_RR. > > libkse and libc_r default to SCHED_RR (SCHED_OTHER=SCHED_RR). > >>> I think the way that will always work is to lower the >>> priority and raise it back again after the yield, when >>> using thread priorities. This should work for libthr, >>> libc_r, and libkse under all versions of the OS. >> >> On the surface this sounded promising, but I can envision >> at least one case where temporarily lowering a thread >> priority will not work very well. Take three threads A, B & >> C each with different priorities: A highest, C lowest. Let's >> say A is in a busy loop calling Thread.Yield(). B is in a busy >> loop also calling Thread.Yield(). C is doing something that >> needs some time slices every so often. A calls Thread.Yield(), >> lowers priority to C's level, B gets some time next, it calls >> Thread.Yield(), lowers priority to C's level. A, B, C are all >> at equal level now. Perhaps C will get some time first, or B, >> or A. Suppose the order is C first, B next. I forgot to mention here B's priority gets restored until the next time it calls yield again, creating the possibility of starvation of A. >> A will only get >> a time slice if B continues to call yield and by chance the >> system schedules A before B. The behavior becomes >> non-deterministic. The worst case is A is starved. > > No, if the threads are at equal priority, they will always > run. The system, either the userland scheduler or the kernel, > will ensure the threads get scheduled equally. For the > kernel scheduler, "equally" depends on their resource usage. > > I would just totally ignore setting thread priorities > unless the UseThreadPriority knob is set. The kernel > scheduler (for libthr) doesn't seem to care what a thread's > priority is anyways unless it is in the real-time class. > That way, all threads will be at the default priority > by default ;-) I think that's a fine idea. Just changing the default to be UseThreadPriority=false and completely remove the os_sleep() bits. If Sun corrects the API or the TCK tests the default can be changed back. -Kurt