From owner-freebsd-performance@FreeBSD.ORG Sun Sep 16 04:47:45 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 EEDF916A41B; Sun, 16 Sep 2007 04:47:42 +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 0450213C481; Sun, 16 Sep 2007 04:47:41 +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 l8G4leid001906; Sun, 16 Sep 2007 00:47:40 -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 00:47:40 -0400 (EDT) Date: Sun, 16 Sep 2007 00:47:40 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kurt Miller In-Reply-To: <200709152250.50879.kurt@intricatesoftware.com> 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 , performance@freebsd.org, freebsd-java@freebsd.org 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 04:47:45 -0000 On Sat, 15 Sep 2007, Kurt Miller wrote: > > Hello Kris, > > I recall why I added the os_sleep() call. While working on the certification > testing one of the JCK tests was deadlocking. The test itself was faulty in > that it created a high priority thread in a tight yield loop. Since > pthread_yield() on a single processor system will not yield to lower > priority threads, the higher priority thread effectively blocked the > lower priority thread from running and the test deadlocked. > > I filed a formal appeal to have the JCK test corrected. However since the > api states: > > http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#yield() > "Causes the currently executing thread object to temporarily pause > and allow other threads to execute." > > the appeal was denied. I further argued that many publications written > by or or-authored by Sun employees state that Thread.yield() can not > be relied upon in this fashion: [ ... ] It's odd that Sun would take this position since the POSIX behavior for sched_yield() is: The sched_yield() function shall force the running thread to relinquish the processor until it again becomes the head of its thread list. It takes no arguments. The "its thread list" mentioned above is the list of threads for its given priority. POSIX has a notion of a list of threads for each given priority; in SCHED_RR and SCHED_FIFO scheduling the higher priority threads will always run before lower priority threads. Sun's defined Java behavior, or their interpretation, of Thread.yield() is not obtainable on a POSIX compliant system using sched_yield() (or pthread_yield()). Even using scope system threads or libthr, the kernel scheduler should run the higher priority threads before lower priority threads. I suspect that Sun will eventually be forced to change their documented behavior for Thread.yield(). -- DE From owner-freebsd-performance@FreeBSD.ORG Sun Sep 16 05:52:24 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 7427E16A417 for ; Sun, 16 Sep 2007 05:52:24 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id E632613C469 for ; Sun, 16 Sep 2007 05:52:23 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so919136nfb for ; Sat, 15 Sep 2007 22:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=KtLsE7RsPnk1Mrbhw0byorqWWv0pa1bpf5Ur7lJEo5A=; b=I3Zz1Z2vFyahlMUV6TDFaSDV9d6+GEHsCBtokIWpVdk4EbTTeYMU75gs0g2XKplzTIlKgvjrsnbpvuUMdjGw6GCQPd5dhu/NBu9kJmxI8qv49z+tKrgeiwBcyeo6cZUKQRI36/T8bcP2LHZtwwgdbWXGgYYcXMuB552XdJ1tz8Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tZT7wIo31d6mX5GONdxJGuoMBYr6Xvt3bbHJw9gAYgxR1KJReW6HmKVQQDyx/IcSVt1QHe8rIR3XoxTKQXxZzeeRgjNfy4Amv6F6njJEBJh0AA1XBavwuYAMspso3PklZT9o1CyL2I9n4gBr184Bp5R9ECSvSazS9dCqtS16eqA= Received: by 10.78.132.2 with SMTP id f2mr1890799hud.1189920329524; Sat, 15 Sep 2007 22:25:29 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Sat, 15 Sep 2007 22:25:29 -0700 (PDT) Message-ID: Date: Sat, 15 Sep 2007 22:25:29 -0700 From: "Kip Macy" To: "Daniel Eischen" , "Kurt Miller" , java@freebsd.org, "Kris Kennaway" , performance@freebsd.org, freebsd-java@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46EC1B55.4060202@FreeBSD.org> <200709152250.50879.kurt@intricatesoftware.com> Cc: Subject: Re: Massive performance loss from OS::sleep hack X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 05:52:24 -0000 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. On 9/15/07, Daniel Eischen wrote: > On Sat, 15 Sep 2007, Kurt Miller wrote: > > > > Hello Kris, > > > > I recall why I added the os_sleep() call. While working on the > certification > > testing one of the JCK tests was deadlocking. The test itself was faulty > in > > that it created a high priority thread in a tight yield loop. Since > > pthread_yield() on a single processor system will not yield to lower > > priority threads, the higher priority thread effectively blocked the > > lower priority thread from running and the test deadlocked. > > > > I filed a formal appeal to have the JCK test corrected. However since the > > api states: > > > > http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#yield() > > "Causes the currently executing thread object to temporarily pause > > and allow other threads to execute." > > > > the appeal was denied. I further argued that many publications written > > by or or-authored by Sun employees state that Thread.yield() can not > > be relied upon in this fashion: > > [ ... ] > > It's odd that Sun would take this position since the POSIX behavior > for sched_yield() is: > > The sched_yield() function shall force the running thread to > relinquish the processor until it again becomes the head of its > thread list. It takes no arguments. > > The "its thread list" mentioned above is the list of threads for its > given priority. POSIX has a notion of a list of threads for each > given priority; in SCHED_RR and SCHED_FIFO scheduling the higher > priority threads will always run before lower priority threads. > > Sun's defined Java behavior, or their interpretation, of Thread.yield() > is not obtainable on a POSIX compliant system using sched_yield() > (or pthread_yield()). Even using scope system threads or libthr, > the kernel scheduler should run the higher priority threads before > lower priority threads. > > I suspect that Sun will eventually be forced to change their > documented behavior for Thread.yield(). > > -- > DE > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to > "freebsd-performance-unsubscribe@freebsd.org" > From owner-freebsd-performance@FreeBSD.ORG Sun Sep 16 10:16:38 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 5E77E16A418; Sun, 16 Sep 2007 10:16:38 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 5290613C461; Sun, 16 Sep 2007 10:16:33 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46ED0280.8050504@FreeBSD.org> Date: Sun, 16 Sep 2007 12:16:32 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: kurt@intricatesoftware.com References: <46EC1B55.4060202@FreeBSD.org> <200709152250.50879.kurt@intricatesoftware.com> <200709152305.06116.lists@intricatesoftware.com> In-Reply-To: <200709152305.06116.lists@intricatesoftware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: performance@freebsd.org, freebsd-java@freebsd.org Subject: Re: Massive performance loss from OS::sleep hack X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 10:16:38 -0000 Kurt Miller wrote: > On Saturday 15 September 2007 10:50:50 pm Kurt Miller wrote: >> The following are programs I wrote when I isolated the problem. >> If the c program runs ok on 7.0 for both single cpu and mp then >> remove the os_sleep() and try the java program. If that works too >> then you're clear to make the os_sleep() hack only apply to < >> 7.0 and still be able to pass the certification tests. > > Sorry copy/paste glitch. He is the c program again: Thanks, I'll test this out and see where we stand. Kris 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 From owner-freebsd-performance@FreeBSD.ORG Sun Sep 16 02:50:54 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 A140C16A417; Sun, 16 Sep 2007 02:50:54 +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 428A813C45A; Sun, 16 Sep 2007 02:50:54 +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 l8G2ooGX020527; Sat, 15 Sep 2007 22:50:51 -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 l8G2op40022047; Sat, 15 Sep 2007 22:50:51 -0400 (EDT) Received: (from truk@localhost) by seraph.intricatesoftware.com (8.14.1/8.14.1/Submit) id l8G2opq6018558; Sat, 15 Sep 2007 22:50:51 -0400 (EDT) X-Authentication-Warning: seraph.intricatesoftware.com: truk set sender to kurt@intricatesoftware.com using -f From: Kurt Miller To: freebsd-java@freebsd.org Date: Sat, 15 Sep 2007 22:50:50 -0400 User-Agent: KMail/1.9.7 References: <46EC1B55.4060202@FreeBSD.org> In-Reply-To: <46EC1B55.4060202@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709152250.50879.kurt@intricatesoftware.com> 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,AWL X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Score: -1.3 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 X-Mailman-Approved-At: Sun, 16 Sep 2007 16:07:04 +0000 Cc: java@freebsd.org, Kris Kennaway , performance@freebsd.org Subject: Re: Massive performance loss from OS::sleep hack X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 02:50:54 -0000 On Saturday 15 September 2007 01:50:13 pm Kris Kennaway wrote: > Hi, > > I have been running the volano java benchmark > (http://www.volano.com/benchmarks.html) on an 8-core i386 system, and > out of the box jdk15 on FreeBSD performs extremely poorly. The system > is more than 90% idle, and profiling shows that the ~800 threads in the > benchmark are spending most of their time doing short nanosleep() calls. > > > I traced it to the following FreeBSD-specific hack in the jdk: > > // XXXBSD: understand meaning and workaround related to yield > ... > // XXXBSD: done differently in 1.3.1, take a look > int os::sleep(Thread* thread, jlong millis, bool interruptible) { > assert(thread == Thread::current(), "thread consistency check"); > ... > > if (millis <= 0) { > // NOTE: workaround for bug 4338139 > if (thread->is_Java_thread()) { > ThreadBlockInVM tbivm((JavaThread*) thread); > // BSDXXX: Only use pthread_yield here and below if the system thread > // scheduler gives time slices to lower priority threads when yielding. > #ifdef __FreeBSD__ > os_sleep(MinSleepInterval, interruptible); > #else > pthread_yield(); > #endif > > When I removed this hack (i.e. revert to pthread_yield()) I got an > immediate 7-fold performance increase, which brings FreeBSD performance > on par with Solaris. > > What is the reason why this code is necessary? Does FreeBSD's > sched_yield() really have different semantics to the other operating > systems, or was this a libkse bug that was being worked around? Hello Kris, I recall why I added the os_sleep() call. While working on the certification testing one of the JCK tests was deadlocking. The test itself was faulty in that it created a high priority thread in a tight yield loop. Since pthread_yield() on a single processor system will not yield to lower priority threads, the higher priority thread effectively blocked the lower priority thread from running and the test deadlocked. I filed a formal appeal to have the JCK test corrected. However since the api states: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#yield() "Causes the currently executing thread object to temporarily pause and allow other threads to execute." the appeal was denied. I further argued that many publications written by or or-authored by Sun employees state that Thread.yield() can not be relied upon in this fashion: "However, I believe there are other less authoritative sources of information that support the position that yield() can not expected to allow lower priority threads to execute in all cases. For example the following Sun document describes yield() as advisory only and not to depend on it for correctness: http://java.sun.com/j2se/1.5.0/docs/guide/vm/thread-priorities.html#general The document also refers to a Sun published book, "Effective Java Programming Language Guide" that describes yield() should not be relied on for correctness and portability. Another book I have specifically addresses the topic. It states that most schedulers do not stop the yielding thread from running in favor of a thread of lower priority. This is from the Sybex "Complete Java 2 Certification Study Guide" co-authored by a Sun employee. The publications I have referred to above present a case that the api description of yield() doesn't fully describe the expected behavior of the function when combined with thread priorities. While they are not the authoritive publications on the function, I think they represent the general historical interpretation of the expected behavior." In the end I was not able to convince Sun to change the JCK test so the os_sleep() call was added. I see in my notes that kse on a single cpu system had the issue but thr didn't (this is on 6.1-release). Perhaps now that thr is the default on 7.0 this hack can be made conditional and only applied to < 7.0. The following are programs I wrote when I isolated the problem. If the c program runs ok on 7.0 for both single cpu and mp then remove the os_sleep() and try the java program. If that works too then you're clear to make the os_sleep() hack only apply to < 7.0 and still be able to pass the certification tests. Regards, -Kurt ----------- #include #include #include #include #include #include #include #include volatile int init=0; volatile int interrupt=0; static void * yielder(void *arg) { init = 1; while (1) { pthread_yield(); } } static void sighandler(int sig) { interrupt = 1; printf("sighandler\n"); static void sighandler(int sig) { interrupt = 1; printf("sighandler\n"); } static void waitForInit() { struct timespec t, rt; static void waitForInit() { struct timespec t, rt; while (init == 0) { t.tv_sec = 0; t.tv_nsec = 100000; nanosleep(&t, &rt); } } static void waitForInterrupt() { struct timespec t, rt; while (interrupt == 0) { t.tv_sec = 0; t.tv_nsec = 100000; nanosleep(&t, &rt); } } int main(int argc, char *argv[]) { pthread_t yldr; pthread_attr_t attr; struct sigaction act; /* Install a signal handler for SIGUSR1 */ sigemptyset (&act.sa_mask); sigaddset (&act.sa_mask, SIGUSR1); act.sa_handler = sighandler; act.sa_flags = 0; sigaction (SIGUSR1, &act, NULL); pthread_attr_init(&attr); pthread_attr_setschedpolicy(&attr, SCHED_FIFO); pthread_create(&yldr, &attr, yielder, NULL); pthread_setprio(yldr, 16); waitForInit(); if(pthread_kill(yldr, SIGUSR1) != 0) printf("pthread_kill failed with errno = %d\n", errno); waitForInterrupt(); } --------------------- public class yieldTest { public static void main(String[] args) { yielderThread thread = new yielderThread(); thread.setPriority(Thread.NORM_PRIORITY+1); thread.start(); thread.waitForInit(); thread.interrupt(); try { thread.join(); } catch (java.lang.InterruptedException ie) { } } } class yielderThread extends Thread { volatile boolean init = false; void waitForInit() { while (!init) { try { Thread.sleep(100); } catch (InterruptedException e) { } } } public void run() { init = true; while(!isInterrupted()) { yield(); } } } From owner-freebsd-performance@FreeBSD.ORG Sun Sep 16 03:05:09 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 894F116A417; Sun, 16 Sep 2007 03:05:09 +0000 (UTC) (envelope-from lists@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 2348813C457; Sun, 16 Sep 2007 03:05:09 +0000 (UTC) (envelope-from lists@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 l8G355nK021833; Sat, 15 Sep 2007 23:05:06 -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 l8G356Zp030484; Sat, 15 Sep 2007 23:05:06 -0400 (EDT) Received: (from truk@localhost) by seraph.intricatesoftware.com (8.14.1/8.14.1/Submit) id l8G356SB025431; Sat, 15 Sep 2007 23:05:06 -0400 (EDT) X-Authentication-Warning: seraph.intricatesoftware.com: truk set sender to lists@intricatesoftware.com using -f From: Kurt Miller To: freebsd-java@freebsd.org Date: Sat, 15 Sep 2007 23:05:05 -0400 User-Agent: KMail/1.9.7 References: <46EC1B55.4060202@FreeBSD.org> <200709152250.50879.kurt@intricatesoftware.com> In-Reply-To: <200709152250.50879.kurt@intricatesoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709152305.06116.lists@intricatesoftware.com> 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 X-Mailman-Approved-At: Sun, 16 Sep 2007 16:07:04 +0000 Cc: Kris Kennaway , performance@freebsd.org 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: kurt@intricatesoftware.com List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 03:05:09 -0000 On Saturday 15 September 2007 10:50:50 pm Kurt Miller wrote: > The following are programs I wrote when I isolated the problem. > If the c program runs ok on 7.0 for both single cpu and mp then > remove the os_sleep() and try the java program. If that works too > then you're clear to make the os_sleep() hack only apply to < > 7.0 and still be able to pass the certification tests. Sorry copy/paste glitch. He is the c program again: #include #include #include #include #include #include #include #include volatile int init=0; volatile int interrupt=0; static void * yielder(void *arg) { init = 1; while (1) { pthread_yield(); } } static void sighandler(int sig) { interrupt = 1; printf("sighandler\n"); } static void waitForInit() { struct timespec t, rt; while (init == 0) { t.tv_sec = 0; t.tv_nsec = 100000; nanosleep(&t, &rt); } } static void waitForInterrupt() { struct timespec t, rt; while (interrupt == 0) { t.tv_sec = 0; t.tv_nsec = 100000; nanosleep(&t, &rt); } } int main(int argc, char *argv[]) { pthread_t yldr; pthread_attr_t attr; struct sigaction act; /* Install a signal handler for SIGUSR1 */ sigemptyset (&act.sa_mask); sigaddset (&act.sa_mask, SIGUSR1); act.sa_handler = sighandler; act.sa_flags = 0; sigaction (SIGUSR1, &act, NULL); pthread_attr_init(&attr); pthread_attr_setschedpolicy(&attr, SCHED_FIFO); pthread_create(&yldr, &attr, yielder, NULL); pthread_setprio(yldr, 16); waitForInit(); if(pthread_kill(yldr, SIGUSR1) != 0) printf("pthread_kill failed with errno = %d\n", errno); waitForInterrupt(); } From owner-freebsd-performance@FreeBSD.ORG Sun Sep 16 19:56:53 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 1768716A419 for ; Sun, 16 Sep 2007 19:56:53 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.187]) by mx1.freebsd.org (Postfix) with ESMTP id E75AF13C45E for ; Sun, 16 Sep 2007 19:56:52 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so1040035rvb for ; Sun, 16 Sep 2007 12:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=B9UmwWyct4ImbUGW5xXk/HHlVLhZK+nTa7D7gvIFLC8=; b=gUOBUUT6CEGNbQVjJAZAjvgemfGoRm0oHsOALn+Pb5xcBnhmF4S5qEl101gcdCXU3JRnh3YoBdwbYIh8BIJm2ZGS9lktZ8byDcbqUp5DQQTcNPKHN3lrCcQknLzXktUZ4b1qpnN/xQTIGDxSU0ek4khkcaKfGB+oja8SLHv1B9g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ed2licbUprFB+nmEoj5JmlnlOd1eSYEAgZTrmbK2z5KAqcGb3TQl0i1T2qKmMeN892ju9vj+BN+nDG86zX4pfYyEK3qe2L3j4RA4IfeCujNrrCydQyETr2EKg+LY/tv3OBBZhP8gf/5wevDIYzpoKknWLiXOlIKJYSHVg6zQVWw= Received: by 10.114.37.1 with SMTP id k1mr1784793wak.1189972609701; Sun, 16 Sep 2007 12:56:49 -0700 (PDT) Received: by 10.114.13.15 with HTTP; Sun, 16 Sep 2007 12:56:49 -0700 (PDT) Message-ID: Date: Sun, 16 Sep 2007 12:56:49 -0700 From: "Kip Macy" To: "Daniel Eischen" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46EC1B55.4060202@FreeBSD.org> <200709152250.50879.kurt@intricatesoftware.com> 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 List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2007 19:56:53 -0000 On 9/16/07, Daniel Eischen wrote: > 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 peIrfect, 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. Yes, if we could hack the jvm to work around this without calling sleep that would be better yet. However, making java work well is more important than keeping the interface clean. > This test would fail even on Solaris if you use SCHED_RR or SCHED_FIFO > since it is POSIX compliant for those scheduling classes. I honestly don't think it matters. The JCK using it implies that there are probably java apps that rely on this defective behavior. I would be willing to bet that Solaris and Java developers at Sun already had this argument and the Java developers won :-(. -Kip From owner-freebsd-performance@FreeBSD.ORG Mon Sep 17 01:16:25 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 B7D1516A417; Mon, 17 Sep 2007 01:16:25 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A382E13C467; Mon, 17 Sep 2007 01:16:25 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 1985B1A4D7C; Sun, 16 Sep 2007 17:59:12 -0700 (PDT) Date: Sun, 16 Sep 2007 17:59:12 -0700 From: Alfred Perlstein To: Daniel Eischen Message-ID: <20070917005912.GT79417@elvis.mu.org> References: <46EC1B55.4060202@FreeBSD.org> <200709152250.50879.kurt@intricatesoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: performance@freebsd.org, Kip Macy , Kris Kennaway , java@freebsd.org, Kurt Miller , freebsd-java@freebsd.org Subject: Re: Massive performance loss from OS::sleep hack X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 01:16:26 -0000 * Daniel Eischen [070916 08:46] wrote: > 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. Since Sun wasn't concenred with correctness, just performance, I don't think we have to shoot for the moon here. I think your suggestion about temporarily lowering priority makes sense. -Alfred From owner-freebsd-performance@FreeBSD.ORG Mon Sep 17 01:47:56 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 7D68F16A417; Mon, 17 Sep 2007 01:47:56 +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 0EEE613C48D; Mon, 17 Sep 2007 01:47:55 +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 l8H1lrbN023210; Sun, 16 Sep 2007 21:47:54 -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 l8H1lrpZ004358; Sun, 16 Sep 2007 21:47:54 -0400 (EDT) Message-ID: <46EDDCC9.90403@intricatesoftware.com> Date: Sun, 16 Sep 2007 21:47:53 -0400 From: Kurt Miller User-Agent: Thunderbird 2.0.0.5 (X11/20070804) MIME-Version: 1.0 To: Kip Macy References: <46EC1B55.4060202@FreeBSD.org> <200709152250.50879.kurt@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: Daniel Eischen , Kris Kennaway , performance@freebsd.org, freebsd-java@freebsd.org Subject: Re: Massive performance loss from OS::sleep hack X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 01:47:56 -0000 Kip Macy wrote: > Yes, if we could hack the jvm to work around this without calling > sleep that would be better yet. However, making java work well is more > important than keeping the interface clean. One possible alternative is to not honor thread priorities in the jdk by default. In hotspot/src/os/linux/vm/os_linux.cpp I see this comment: // Note: LinuxThreads only honor thread priority for real time threads. // sched_priority is ignored if policy is SCHED_OTHER. This function is // equivalent to a "noop" on current Linux platforms. OSReturn os::set_native_priority(Thread* thread, int newpri) { which leads me to believe linux doesn't honor thread priorities in the jdk. Perhaps someone could verify that on a linux box. If linux and/or windows doesn't actually honor thread priorities I don't see why we need to. IIRC, there weren't any specific JCK tests that validated a higher priority thread actually got more time then a lower one (I could be wrong on that since there was > 30k tests in the jck). So we could default UseThreadPriorities to false and make the os_sleep() call only be used when UseThreadPriorities is true (i.e. the user explicitly sets -XX:+UseThreadPriorities). Can someone check out linux to see if it indeed supports or ignores thread priorities for java programs? -Kurt From owner-freebsd-performance@FreeBSD.ORG Mon Sep 17 02:34:10 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 D875D16A417; Mon, 17 Sep 2007 02:34:10 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C6F3B13C457; Mon, 17 Sep 2007 02:34:10 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8H2Y77C017951; Mon, 17 Sep 2007 02:34:08 GMT (envelope-from davidxu@freebsd.org) Message-ID: <46EDE7CF.8060100@freebsd.org> Date: Mon, 17 Sep 2007 10:34:55 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Kennaway References: <46EC1B55.4060202@FreeBSD.org> In-Reply-To: <46EC1B55.4060202@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: java@freebsd.org, performance@freebsd.org Subject: Re: Massive performance loss from OS::sleep hack X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 02:34:10 -0000 Kris Kennaway wrote: > Hi, > > I have been running the volano java benchmark > (http://www.volano.com/benchmarks.html) on an 8-core i386 system, and > out of the box jdk15 on FreeBSD performs extremely poorly. The system > is more than 90% idle, and profiling shows that the ~800 threads in the > benchmark are spending most of their time doing short nanosleep() calls. > > > I traced it to the following FreeBSD-specific hack in the jdk: > > // XXXBSD: understand meaning and workaround related to yield > ... > // XXXBSD: done differently in 1.3.1, take a look > int os::sleep(Thread* thread, jlong millis, bool interruptible) { > assert(thread == Thread::current(), "thread consistency check"); > ... > > if (millis <= 0) { > // NOTE: workaround for bug 4338139 > if (thread->is_Java_thread()) { > ThreadBlockInVM tbivm((JavaThread*) thread); > // BSDXXX: Only use pthread_yield here and below if the system thread > // scheduler gives time slices to lower priority threads when yielding. > #ifdef __FreeBSD__ > os_sleep(MinSleepInterval, interruptible); > #else > pthread_yield(); > #endif > > When I removed this hack (i.e. revert to pthread_yield()) I got an > immediate 7-fold performance increase, which brings FreeBSD performance > on par with Solaris. > > What is the reason why this code is necessary? Does FreeBSD's > sched_yield() really have different semantics to the other operating > systems, or was this a libkse bug that was being worked around? > > Kris Yeah, our sched_yield() really works well, in kernel, if the thread scheduling policy is SCHED_OTHER (time-sharing), scheduler temporarily lowers its priority to PRI_MAX_TIMESHARE, it is enough to give some CPU time to other threads. Why doesn't the UNIX time-sharing work for java ? Regards, David Xu From owner-freebsd-performance@FreeBSD.ORG Mon Sep 17 12:59:12 2007 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E47716A41A for ; Mon, 17 Sep 2007 12:59:12 +0000 (UTC) (envelope-from girgen@pingpong.net) Received: from melon.pingpong.net (melon.pingpong.net [195.178.174.161]) by mx1.freebsd.org (Postfix) with ESMTP id 52DC713C459 for ; Mon, 17 Sep 2007 12:59:12 +0000 (UTC) (envelope-from girgen@pingpong.net) Received: from localhost (localhost.pingpong.net [127.0.0.1]) by melon.pingpong.net (Postfix) with ESMTP id 733175084E; Mon, 17 Sep 2007 14:59:10 +0200 (CEST) Received: from melon.pingpong.net ([127.0.0.1]) by localhost (melon.pingpong.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 68228-02-7; Mon, 17 Sep 2007 14:59:10 +0200 (CEST) Received: from [192.168.1.187] (unknown [213.136.40.204]) by melon.pingpong.net (Postfix) with ESMTP id DF91D5084D; Mon, 17 Sep 2007 14:59:09 +0200 (CEST) Date: Mon, 17 Sep 2007 14:59:08 +0200 From: Palle Girgensohn To: Francisco Reyes Message-ID: In-Reply-To: References: <1F219879A7E5C565C96109FF@c-2f56e155.1521-1-64736c12.cust.bredbandsbolaget.se> <26F41A5DACB2D2CB43A5829E@c-6254e155.1521-1-64736c12.cust.bredbandsbolaget.se> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at pingpong.net Cc: freebsd-performance@freebsd.org Subject: Re: AMD or Intel? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 12:59:12 -0000 --On fredag, september 14, 2007 18.44.35 -0400 Francisco Reyes wrote: > Palle Girgensohn writes: > >> Sorry, my mistake, more like a percent per day at the moment... > > If you have 16GB and you got 1% per day.. in less than 100 days you would > be at 32GB.. If growth continues you will theoretically be at 60GB+ > within a year. > > We are planning about 16 GB RAM, actually. Maybe it is overkill? > > If you can afford it the more the merrier.. given that you likely will > have this machine for a good couple of years.. as your data grow what was > once "overkill" will become "a good amount" of memory. So I would say do > get the 16GB if the budget allows it. True... > > We will probably go for SCSI. HP DL380 with "HP SmartArray", aka ciss. > > How will you monitor disk failures? Does that controller can be monitored > with FreeBSD in some way? I believe it can, not sure how well, though. Status control can be done with this util: /usr/ports/sysutils/cciss_vol_status Thanks Palle From owner-freebsd-performance@FreeBSD.ORG Tue Sep 18 11:22:06 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 D8D8B16A419; Tue, 18 Sep 2007 11:22:06 +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 A649213C46C; Tue, 18 Sep 2007 11:22:06 +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 l8IBLovm032232; Tue, 18 Sep 2007 07:21:51 -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 l8IBLo9D002600; Tue, 18 Sep 2007 07:21:50 -0400 (EDT) Received: (from truk@localhost) by seraph.intricatesoftware.com (8.14.1/8.14.1/Submit) id l8IBLnd0020322; Tue, 18 Sep 2007 07:21:49 -0400 (EDT) X-Authentication-Warning: seraph.intricatesoftware.com: truk set sender to kurt@intricatesoftware.com using -f From: Kurt Miller To: freebsd-java@freebsd.org Date: Tue, 18 Sep 2007 07:21:48 -0400 User-Agent: KMail/1.9.7 References: <46EC1B55.4060202@FreeBSD.org> <46EDDCC9.90403@intricatesoftware.com> In-Reply-To: <46EDDCC9.90403@intricatesoftware.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_MT77G2sKRW3o4KJ" Message-Id: <200709180721.48995.kurt@intricatesoftware.com> 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 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Daniel Eischen , Kip Macy , Kris Kennaway , performance@freebsd.org Subject: Re: Massive performance loss from OS::sleep hack X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 11:22:07 -0000 --Boundary-00=_MT77G2sKRW3o4KJ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline 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. For 7.0 and up default UseThreadPriorities to true and always use pthread_yield(). For < 7.0 default UseThreadPriorities to false and conditionally use pthread_yield()/os_sleep(). User's can toggle UseThreadPriorities with the command line argument -XX:+UseThreadPriorities -------- files/patch-vm::os_bsd.cpp -------- $FreeBSD: ports/java/jdk15/files/patch-vm::os_bsd.cpp,v 1.7 2007/06/09 05:14:56 glewis Exp $ --- ../../hotspot/src/os/bsd/vm/os_bsd.cpp.orig Mon Sep 17 17:39:33 2007 +++ ../../hotspot/src/os/bsd/vm/os_bsd.cpp Mon Sep 17 20:57:26 2007 @@ -508,7 +508,7 @@ #define getenv(n) ::getenv(n) #ifndef DEFAULT_LD_LIBRARY_PATH -#define DEFAULT_LD_LIBRARY_PATH "/usr/lib" /* See ld.so.1(1) */ +#define DEFAULT_LD_LIBRARY_PATH "/usr/lib:/usr/local/lib" /* See ld.so.1(1) */ #endif #define EXTENSIONS_DIR "/lib/ext" #define ENDORSED_DIR "/lib/endorsed" @@ -2273,11 +2273,14 @@ // BSDXXX: Only use pthread_yield here and below if the system thread // scheduler gives time slices to lower priority threads when yielding. -#ifdef __FreeBSD__ +// pthread_yield() can also be used when thread priorities are disabled. +// Using os_sleep() here causes significant performance degradation. +#if defined(_ALLBSD_SOURCE) && (!defined(__FreeBSD__) || __FreeBSD__ < 7) + if ( UseThreadPriorities ) os_sleep(MinSleepInterval, interruptible); -#else - pthread_yield(); + else #endif + pthread_yield(); #if SOLARIS // XXX - This code was not exercised during the Merlin RC1 @@ -2299,11 +2302,14 @@ // BSDXXX: Only use pthread_yield here and above if the system thread // scheduler gives time slices to lower priority threads when yielding. -#ifdef __FreeBSD__ - os_sleep(MinSleepInterval, interruptible); -#else - pthread_yield(); +// pthread_yield() can be also used when thread priorities are disabled. +// Using os_sleep() here causes significant performance degradation. +#if defined(_ALLBSD_SOURCE) && (!defined(__FreeBSD__) || __FreeBSD__ < 7) + if ( UseThreadPriorities ) + os_sleep(MinSleepInterval, interruptible); + else #endif + pthread_yield(); return 0; } ------- files/patch-vm::globals.hpp -------- $FreeBSD$ --- ../../hotspot/src/share/vm/runtime/globals.hpp.orig Mon Sep 17 10:12:16 2007 +++ ../../hotspot/src/share/vm/runtime/globals.hpp Mon Sep 17 10:20:32 2007 @@ -130,6 +130,12 @@ #define falseInProduct true #endif +#if !defined(_ALLBSD_SOURCE) || (defined(__FreeBSD__) && __FreeBSD__ >= 7) +#define OSUseThreadPriorities true +#else +#define OSUseThreadPriorities false +#endif + // develop flags are settable / visible only during development and are constant in the PRODUCT version // product flags are always settable / visible @@ -2546,7 +2552,7 @@ "beginning to throw OutOfMemoryErrors in each compile") \ \ /* Priorities */ \ - product(bool, UseThreadPriorities, true, \ + product(bool, UseThreadPriorities, OSUseThreadPriorities, \ "Use native thread priorities") \ \ product(intx, ThreadPriorityPolicy, 0, \ --Boundary-00=_MT77G2sKRW3o4KJ-- From owner-freebsd-performance@FreeBSD.ORG Tue Sep 18 12:29:26 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 B85BD16A41A; Tue, 18 Sep 2007 12:29:26 +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 7682313C4EC; Tue, 18 Sep 2007 12:29:24 +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 l8ICTCds007334; Tue, 18 Sep 2007 08:29:12 -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]); Tue, 18 Sep 2007 08:29:12 -0400 (EDT) Date: Tue, 18 Sep 2007 08:29:12 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kurt Miller In-Reply-To: <200709180721.48995.kurt@intricatesoftware.com> Message-ID: References: <46EC1B55.4060202@FreeBSD.org> <46EDDCC9.90403@intricatesoftware.com> <200709180721.48995.kurt@intricatesoftware.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-ID: Content-Disposition: inline Cc: Kip Macy , Kris Kennaway , performance@freebsd.org, freebsd-java@freebsd.org 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: Tue, 18 Sep 2007 12:29:26 -0000 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. 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. As for knobs, it would be nice to be able to turn off the default lowering and raising of priorities for Thread.yield() even when using thread priorities. Most likely, the only applications that relies on that behavior are the TCK tests themselves. I certainly wouldn't expect Thread.yield() to allow a lower priority thread to run. Are you allowed to supply knobs when running the TCK tests? Or does the JVM have to do the right thing by default? -- DE From owner-freebsd-performance@FreeBSD.ORG Tue Sep 18 14:16:13 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 BC04E16A46C; Tue, 18 Sep 2007 14:16:13 +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 5DFC213C4A8; Tue, 18 Sep 2007 14:16:13 +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 l8IEG8Z1000316; Tue, 18 Sep 2007 10:16:08 -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 l8IEG9SG030255; Tue, 18 Sep 2007 10:16:09 -0400 (EDT) Message-ID: <46EFDDA8.2030603@intricatesoftware.com> Date: Tue, 18 Sep 2007 10:16:08 -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> 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-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 14:16:13 -0000 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. > 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. 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. Also to make matters a bit more complicated there are non-java threads to contend with too. There could be some non-java locking involved as well. It would require an investment of someone else's time to work all the potential issues out. > As for knobs, it would be nice to be able to turn off > the default lowering and raising of priorities for > Thread.yield() even when using thread priorities. Most > likely, the only applications that relies on that behavior > are the TCK tests themselves. I certainly wouldn't expect > Thread.yield() to allow a lower priority thread to > run. Considering Sun's reluctance to correct the TCK test, I would venture a guess that there are applications out there that rely on Thread.Yield() to give time to lower priority threads (in-spite of the significant amount of Java books, white papers, certification tests, etc that say not to do that). > Are you allowed to supply knobs when running the TCK > tests? Or does the JVM have to do the right thing by > default? The JVM gets certified on the default threading library for the standard options. Generally the non-standard options (-Xfoo) are not certified. Attempting to certify the JVM for multiple threading libraries, os versions, architectures, and options would be cost prohibitive. I believe what I've suggested provides a solution to the performance issue (at the expense of supporting thread priorities on < 7.0), while not introducing unexpected or non-certifiable behavior. Motivated people on this list should file bug reports w/Sun against the Thread.Yield() API. It is about time Sun clarify the expected behavior of of Thread.Yield() with respect to thread priorities. At a minimum the current description of Thread.Yield() is in conflict with JSR-133: JavaTM Memory Model and Thread Specification, Section 12: "The Java specification does not guarantee preemptive multithreading or any kind of fairness guarantee. There is no hard guarantee that any thread will surrender the CPU and allow other threads to be scheduled." Not to mention the 10 years of non-official publications that say not to rely on Thread.Yield() to do anything portable at all. Regards, -Kurt From owner-freebsd-performance@FreeBSD.ORG Tue Sep 18 17:08:22 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 E0B6216A418; Tue, 18 Sep 2007 17:08:22 +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 9EC6013C45A; Tue, 18 Sep 2007 17:08:22 +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 l8IH8LVo028362; Tue, 18 Sep 2007 13:08:21 -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]); Tue, 18 Sep 2007 13:08:21 -0400 (EDT) Date: Tue, 18 Sep 2007 13:08:21 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kurt Miller In-Reply-To: <46EFDDA8.2030603@intricatesoftware.com> Message-ID: References: <46EC1B55.4060202@FreeBSD.org> <46EDDCC9.90403@intricatesoftware.com> <200709180721.48995.kurt@intricatesoftware.com> <46EFDDA8.2030603@intricatesoftware.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kip Macy , Kris Kennaway , performance@freebsd.org, freebsd-java@freebsd.org 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: Tue, 18 Sep 2007 17:08:23 -0000 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. 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 ;-) -- DE From owner-freebsd-performance@FreeBSD.ORG Tue Sep 18 17:28:51 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 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-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning 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 From owner-freebsd-performance@FreeBSD.ORG Tue Sep 18 18:01:04 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 CC0F316A41A; Tue, 18 Sep 2007 18:01:04 +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 8B95413C4D5; Tue, 18 Sep 2007 18:01:04 +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 l8II13ji007686; Tue, 18 Sep 2007 14:01:03 -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]); Tue, 18 Sep 2007 14:01:03 -0400 (EDT) Date: Tue, 18 Sep 2007 14:01:03 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kurt Miller In-Reply-To: <46F00ACF.1080700@intricatesoftware.com> Message-ID: References: <46EC1B55.4060202@FreeBSD.org> <46EDDCC9.90403@intricatesoftware.com> <200709180721.48995.kurt@intricatesoftware.com> <46EFDDA8.2030603@intricatesoftware.com> <46F00ACF.1080700@intricatesoftware.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kip Macy , Kris Kennaway , performance@freebsd.org, freebsd-java@freebsd.org 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: Tue, 18 Sep 2007 18:01:04 -0000 On Tue, 18 Sep 2007, Kurt Miller wrote: > Daniel Eischen wrote: >> >> 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. Yes, and the Java spec (at least for Thread.yield()) is also saying that priorities are meaningless. They can't just say that Thread.yield() allows other threads to run without defining their behavior. How many threads can run? All? Is it acceptable for yield to allow only one thread to run, and for only one clock tick? What is the point of having priorities in Java if they can't be used reliably? But I digress... -- DE From owner-freebsd-performance@FreeBSD.ORG Tue Sep 18 19:17:18 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 3AAF016A420; Tue, 18 Sep 2007 19:17:18 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id D78F313C45B; Tue, 18 Sep 2007 19:17:15 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46F0243A.8020902@FreeBSD.org> Date: Tue, 18 Sep 2007 21:17:14 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Kurt Miller References: <46EC1B55.4060202@FreeBSD.org> <46EDDCC9.90403@intricatesoftware.com> <200709180721.48995.kurt@intricatesoftware.com> In-Reply-To: <200709180721.48995.kurt@intricatesoftware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Kip Macy , performance@freebsd.org, freebsd-java@freebsd.org Subject: Re: Massive performance loss from OS::sleep hack X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2007 19:17:18 -0000 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. > > For 7.0 and up default UseThreadPriorities to true and always > use pthread_yield(). For < 7.0 default UseThreadPriorities to > false and conditionally use pthread_yield()/os_sleep(). User's > can toggle UseThreadPriorities with the command line argument > -XX:+UseThreadPriorities Do we know that 6.x requires the old behaviour? Maybe it can default to on there too. Otherwise this looks good to my eyeball (but the DEFAULT_LD_LIBRARY_PATH change looks unrelated) -#define DEFAULT_LD_LIBRARY_PATH "/usr/lib" /* See ld.so.1(1) */ +#define DEFAULT_LD_LIBRARY_PATH "/usr/lib:/usr/local/lib" /* See ld.so.1(1) Kris From owner-freebsd-performance@FreeBSD.ORG Wed Sep 19 02:13:04 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 3C5F116A41A; Wed, 19 Sep 2007 02:13:04 +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 AE5CA13C474; Wed, 19 Sep 2007 02:13:03 +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 l8J2D05f030590; Tue, 18 Sep 2007 22:13:01 -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 l8J2D1gE025066; Tue, 18 Sep 2007 22:13:01 -0400 (EDT) Received: (from truk@localhost) by seraph.intricatesoftware.com (8.14.1/8.14.1/Submit) id l8J2D1X0010907; Tue, 18 Sep 2007 22:13:01 -0400 (EDT) X-Authentication-Warning: seraph.intricatesoftware.com: truk set sender to kurt@intricatesoftware.com using -f From: Kurt Miller To: freebsd-java@freebsd.org Date: Tue, 18 Sep 2007 22:13:00 -0400 User-Agent: KMail/1.9.7 References: <46EC1B55.4060202@FreeBSD.org> <200709180721.48995.kurt@intricatesoftware.com> <46F0243A.8020902@FreeBSD.org> In-Reply-To: <46F0243A.8020902@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709182213.00777.kurt@intricatesoftware.com> 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: Daniel Eischen , Kip Macy , Kris Kennaway , performance@freebsd.org Subject: Re: Massive performance loss from OS::sleep hack X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 02:13:04 -0000 On Tuesday 18 September 2007 03:17:14 pm Kris Kennaway wrote: > 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. > > > > For 7.0 and up default UseThreadPriorities to true and always > > use pthread_yield(). For < 7.0 default UseThreadPriorities to > > false and conditionally use pthread_yield()/os_sleep(). User's > > can toggle UseThreadPriorities with the command line argument > > -XX:+UseThreadPriorities > > Do we know that 6.x requires the old behaviour? Maybe it can default to > on there too. Otherwise this looks good to my eyeball (but the > DEFAULT_LD_LIBRARY_PATH change looks unrelated) > > -#define DEFAULT_LD_LIBRARY_PATH "/usr/lib" /* See ld.so.1(1) */ > +#define DEFAULT_LD_LIBRARY_PATH "/usr/lib:/usr/local/lib" /* See > ld.so.1(1) Yea I messed up the DEFAULT_LD_LIBRARY_PATH part. I didn't intend to change that segment of the existing os_bsd.cpp patch. Regarding 6.x it either needs UseThreadPriorities defaulted to false or the os_sleep hack. After discussing the options with Daniel we agree that defaulting UseThreadPriorities to false and eliminating the os_sleep hack for all versions is the most consitant approach. The following is a CVS diff of ports/java/jdk15 that updates the port to fix the performance issue plus an alternative method to setting DEFAULT_LD_LIBRARY_PATH without patching and substituting it: Index: Makefile =================================================================== RCS file: /home/ncvs/ports/java/jdk15/Makefile,v retrieving revision 1.135 diff -u -r1.135 Makefile --- Makefile 7 Sep 2007 20:41:52 -0000 1.135 +++ Makefile 19 Sep 2007 01:53:17 -0000 @@ -7,7 +7,7 @@ PORTNAME= jdk PORTVERSION= ${JDK_VERSION}.${JDK_UPDATE_VERSION}p${JDK_PATCHSET_VERSION} -PORTREVISION= 1 +PORTREVISION= 2 PORTEPOCH= 1 CATEGORIES= java devel MASTER_SITES= # http://download.java.net/tiger/ @@ -129,6 +129,7 @@ MAKE_ENV+= ALT_BOOTDIR="${BOOTSTRAPJDKDIR}" \ ALT_MOTIF_DIR="${X11BASE}" \ + DEFAULT_LD_LIBRARY_PATH="/usr/lib:${LOCALBASE}/lib" \ SYS_CFLAGS="${CFLAGS}" \ LANG="C" \ JAVA_HOME="" \ @@ -161,7 +162,6 @@ JDKIMAGEDIR= ${WRKSRC}/../build/bsd-${HOTSPOTARCH}/j2sdk-image JDKIMAGEDIR_G= ${WRKSRC}/../build/bsd-${HOTSPOTARCH}/j2sdk-debug-image -LOCAL_FILES= ../../hotspot/src/os/bsd/vm/os_bsd.cpp PTHREAD_FILES= ../../hotspot/build/bsd/makefiles/vm.make \ ../../j2se/make/com/sun/java/pack/Makefile \ ../../j2se/make/common/Defs.gmk \ @@ -265,10 +265,6 @@ .endif post-patch: - @for file in ${LOCAL_FILES}; do \ - ${REINPLACE_CMD} -e "s:%%LOCALBASE%%:${LOCALBASE}:" \ - ${WRKSRC}/$${file}; \ - done @for file in ${PTHREAD_FILES}; do \ ${REINPLACE_CMD} -e "s:-pthread:${PTHREAD_LIBS}:g" \ ${WRKSRC}/$${file}; \ Index: files/patch-vm::globals.hpp =================================================================== RCS file: files/patch-vm::globals.hpp diff -N files/patch-vm::globals.hpp --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ files/patch-vm::globals.hpp 19 Sep 2007 01:53:17 -0000 @@ -0,0 +1,26 @@ +$FreeBSD$ + +--- ../../hotspot/src/share/vm/runtime/globals.hpp.orig Wed May 2 04:01:50 2007 ++++ ../../hotspot/src/share/vm/runtime/globals.hpp Tue Sep 18 21:40:44 2007 +@@ -130,6 +130,12 @@ + #define falseInProduct true + #endif + ++#if defined(_ALLBSD_SOURCE) ++#define OSUseThreadPriorities false ++#else ++#define OSUseThreadPriorities true ++#endif ++ + // develop flags are settable / visible only during development and are constant in the PRODUCT version + // product flags are always settable / visible + +@@ -2546,7 +2552,7 @@ + "beginning to throw OutOfMemoryErrors in each compile") \ + \ + /* Priorities */ \ +- product(bool, UseThreadPriorities, true, \ ++ product(bool, UseThreadPriorities, OSUseThreadPriorities, \ + "Use native thread priorities") \ + \ + product(intx, ThreadPriorityPolicy, 0, \ Index: files/patch-vm::os_bsd.cpp =================================================================== RCS file: /home/ncvs/ports/java/jdk15/files/patch-vm::os_bsd.cpp,v retrieving revision 1.7 diff -u -r1.7 patch-vm::os_bsd.cpp --- files/patch-vm::os_bsd.cpp 9 Jun 2007 05:14:56 -0000 1.7 +++ files/patch-vm::os_bsd.cpp 19 Sep 2007 01:53:17 -0000 @@ -1,13 +1,32 @@ $FreeBSD: ports/java/jdk15/files/patch-vm::os_bsd.cpp,v 1.7 2007/06/09 05:14:56 glewis Exp $ ---- ../../hotspot/src/os/bsd/vm/os_bsd.cpp Sun Jun 3 18:46:31 2007 -+++ ../../hotspot/src/os/bsd/vm/os_bsd.cpp.orig Sun Jun 3 18:47:28 2007 -@@ -499,7 +499,7 @@ - #define getenv(n) ::getenv(n) +--- ../../hotspot/src/os/bsd/vm/os_bsd.cpp.orig Mon Sep 17 21:03:04 2007 ++++ ../../hotspot/src/os/bsd/vm/os_bsd.cpp Tue Sep 18 21:36:51 2007 +@@ -2271,13 +2271,7 @@ + if (thread->is_Java_thread()) { + ThreadBlockInVM tbivm((JavaThread*) thread); + +-// BSDXXX: Only use pthread_yield here and below if the system thread +-// scheduler gives time slices to lower priority threads when yielding. +-#ifdef __FreeBSD__ +- os_sleep(MinSleepInterval, interruptible); +-#else + pthread_yield(); +-#endif + + #if SOLARIS + // XXX - This code was not exercised during the Merlin RC1 +@@ -2297,13 +2291,7 @@ + return 0; + } + +-// BSDXXX: Only use pthread_yield here and above if the system thread +-// scheduler gives time slices to lower priority threads when yielding. +-#ifdef __FreeBSD__ +- os_sleep(MinSleepInterval, interruptible); +-#else + pthread_yield(); +-#endif + return 0; + } - #ifndef DEFAULT_LD_LIBRARY_PATH --#define DEFAULT_LD_LIBRARY_PATH "/usr/lib" /* See ld.so.1(1) */ -+#define DEFAULT_LD_LIBRARY_PATH "/usr/lib:%%LOCALBASE%%/lib" /* See ld.so.1 (1) */ - #endif - #define EXTENSIONS_DIR "/lib/ext" - #define ENDORSED_DIR "/lib/endorsed" From owner-freebsd-performance@FreeBSD.ORG Wed Sep 19 10:16:57 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 C011516A419; Wed, 19 Sep 2007 10:16:57 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 1948C13C46A; Wed, 19 Sep 2007 10:16:54 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46F0F714.10608@FreeBSD.org> Date: Wed, 19 Sep 2007 12:16:52 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Kurt Miller References: <46EC1B55.4060202@FreeBSD.org> <200709180721.48995.kurt@intricatesoftware.com> <46F0243A.8020902@FreeBSD.org> <200709182213.00777.kurt@intricatesoftware.com> In-Reply-To: <200709182213.00777.kurt@intricatesoftware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Kip Macy , performance@freebsd.org, freebsd-java@freebsd.org Subject: Re: Massive performance loss from OS::sleep hack X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 10:16:57 -0000 Kurt Miller wrote: > On Tuesday 18 September 2007 03:17:14 pm Kris Kennaway wrote: >> 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. >>> >>> For 7.0 and up default UseThreadPriorities to true and always >>> use pthread_yield(). For < 7.0 default UseThreadPriorities to >>> false and conditionally use pthread_yield()/os_sleep(). User's >>> can toggle UseThreadPriorities with the command line argument >>> -XX:+UseThreadPriorities >> Do we know that 6.x requires the old behaviour? Maybe it can default to >> on there too. Otherwise this looks good to my eyeball (but the >> DEFAULT_LD_LIBRARY_PATH change looks unrelated) >> >> -#define DEFAULT_LD_LIBRARY_PATH "/usr/lib" /* See ld.so.1(1) */ >> +#define DEFAULT_LD_LIBRARY_PATH "/usr/lib:/usr/local/lib" /* See >> ld.so.1(1) > > Yea I messed up the DEFAULT_LD_LIBRARY_PATH part. I didn't intend > to change that segment of the existing os_bsd.cpp patch. > > Regarding 6.x it either needs UseThreadPriorities defaulted to false > or the os_sleep hack. After discussing the options with Daniel we > agree that defaulting UseThreadPriorities to false and eliminating > the os_sleep hack for all versions is the most consitant approach. > > The following is a CVS diff of ports/java/jdk15 that updates the > port to fix the performance issue plus an alternative method > to setting DEFAULT_LD_LIBRARY_PATH without patching and > substituting it: This looks good to me, thanks! Kris From owner-freebsd-performance@FreeBSD.ORG Wed Sep 19 18:24:34 2007 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78D9E16A417 for ; Wed, 19 Sep 2007 18:24:34 +0000 (UTC) (envelope-from kevin@insidesystems.net) Received: from imap.insidesystems.net (imap.insidesystems.net [205.246.16.51]) by mx1.freebsd.org (Postfix) with ESMTP id 4515D13C442 for ; Wed, 19 Sep 2007 18:24:34 +0000 (UTC) (envelope-from kevin@insidesystems.net) Received: from [68.32.227.193] (helo=[10.0.1.3]) by imap.insidesystems.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IY3su-000P0J-Kb; Wed, 19 Sep 2007 18:02:48 +0000 In-Reply-To: References: <1F219879A7E5C565C96109FF@c-2f56e155.1521-1-64736c12.cust.bredbandsbolaget.se> <26F41A5DACB2D2CB43A5829E@c-6254e155.1521-1-64736c12.cust.bredbandsbolaget.se> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Kevin Way Date: Wed, 19 Sep 2007 14:02:47 -0400 To: Francisco Reyes X-Mailer: Apple Mail (2.752.3) Cc: freebsd-performance@freebsd.org, Palle Girgensohn Subject: Re: AMD or Intel? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2007 18:24:34 -0000 On Sep 14, 2007, at 6:44 PM, Francisco Reyes wrote: > Palle Girgensohn writes: > > >> We will probably go for SCSI. HP DL380 with "HP SmartArray", aka >> ciss. >> > > How will you monitor disk failures? Does that controller can be > monitored with FreeBSD in some way? > The disk failures show up in the iLO management log, and in a "camcontrol inquiry". Kevin Way From owner-freebsd-performance@FreeBSD.ORG Thu Sep 20 22:39:41 2007 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECC8516A417 for ; Thu, 20 Sep 2007 22:39:41 +0000 (UTC) (envelope-from decibel@decibel.org) Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by mx1.freebsd.org (Postfix) with ESMTP id A474F13C45A for ; Thu, 20 Sep 2007 22:39:41 +0000 (UTC) (envelope-from decibel@decibel.org) Received: from [10.224.31.73] (unknown [38.98.147.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by noel.decibel.org (Postfix) with ESMTP id 5EC4F5644B; Thu, 20 Sep 2007 15:19:06 +0000 (UTC) In-Reply-To: <1F219879A7E5C565C96109FF@c-2f56e155.1521-1-64736c12.cust.bredbandsbolaget.se> References: <1F219879A7E5C565C96109FF@c-2f56e155.1521-1-64736c12.cust.bredbandsbolaget.se> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <57EF86A6-6062-4F1A-959E-41ABABD3F0CF@decibel.org> Content-Transfer-Encoding: 7bit From: Decibel! Date: Thu, 20 Sep 2007 09:53:18 -0500 To: Palle Girgensohn X-Mailer: Apple Mail (2.752.3) Cc: freebsd-performance@freebsd.org, Francisco Reyes Subject: Re: AMD or Intel? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 22:39:42 -0000 On Sep 13, 2007, at 3:24 PM, Palle Girgensohn wrote: > --On torsdag, torsdag 13 sep 2007 15.07.17 -0400 Francisco Reyes > wrote: > >> Palle Girgensohn writes: >> >>> Now, I hear rumors that AMD is to be preferred over Intel for >>> performance >> >> From what I have read in the past, specially in the postgresql >> list, it >> seems the AMD64 cpus do better with Postgresql. Possibly because of >> better bus architecture. > > I think this is not current information; the new woodcrest > architecture performs mucg better, although this is deduced from > this thread's discussion... Except this thread has largely glossed over the importance of memory bandwidth, which is exactly the reason why Opterons have been beating Xeons for several years. Last I'd heard, things were fairly close between the two, but that would matter on how many cores and physical CPUs you have. It would be good if someone could do a database benchmark for some of the larger parts. Something else worth mentioning... a lot of work is being done to improve PostgreSQL scalability for larger numbers of CPUs. If you're looking at anything over 4 cores, I recommend going to 8.3 ASAP. -- Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 From owner-freebsd-performance@FreeBSD.ORG Fri Sep 21 05:57:33 2007 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7536016A417 for ; Fri, 21 Sep 2007 05:57:33 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id 106DF13C45B for ; Fri, 21 Sep 2007 05:57:32 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so635398nfb for ; Thu, 20 Sep 2007 22:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=hzNo0HmvNapfYEf54+oyiB2jhCkRUjXpY/HDisPbGi0=; b=j54S26HgtbfcDrsVe8C8av+Shy+6/+yEwQXzHpZOtYQyhQTm5x9cC/RN+S/6faxd4DYAY5RsFYvAo7pH0sp1y/ir6VVIXMQtXufEaP0W+O9GxQLB618MUz3uSy97kCK1WyTG6OmyEiNrFHV/QoWWW4ATmBW6x3XOt54zrBMlI+0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Kcx+GemJQNb9Yx1CJ2FO6okh5caH76tAq4TwsXKSOQofPg2KRFOaoBvc39l0qMSxwzwXjPesEaAYp2qoDARY+Qj1PLySocM8rJyeak8weg70dGl984MfWqoakDBDBQwaTQ/k4ARpxzn8k1b/08hrkrb+m8w68Yzgxw7rtBb/I2M= Received: by 10.78.21.7 with SMTP id 7mr1768645huu.1190354251325; Thu, 20 Sep 2007 22:57:31 -0700 (PDT) Received: by 10.78.166.18 with HTTP; Thu, 20 Sep 2007 22:57:31 -0700 (PDT) Message-ID: Date: Fri, 21 Sep 2007 07:57:31 +0200 From: "Claus Guttesen" To: Decibel! In-Reply-To: <57EF86A6-6062-4F1A-959E-41ABABD3F0CF@decibel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1F219879A7E5C565C96109FF@c-2f56e155.1521-1-64736c12.cust.bredbandsbolaget.se> <57EF86A6-6062-4F1A-959E-41ABABD3F0CF@decibel.org> Cc: freebsd-performance@freebsd.org Subject: Re: AMD or Intel? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 05:57:33 -0000 > > I think this is not current information; the new woodcrest > > architecture performs mucg better, although this is deduced from > > this thread's discussion... > > Except this thread has largely glossed over the importance of memory > bandwidth, which is exactly the reason why Opterons have been beating > Xeons for several years. Last I'd heard, things were fairly close > between the two, but that would matter on how many cores and physical > CPUs you have. > > It would be good if someone could do a database benchmark for some of > the larger parts. Like this one??? http://tweakers.net/reviews/657/6 Related links has been mentioned before. Opterons does perform well, especially compared to the first and second generation xeon's. But when woodcrest and clowertown were introduced opteron was more or less left behind. Maby AMD's new barcelona will change the picture. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-performance@FreeBSD.ORG Fri Sep 21 12:07:37 2007 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23F8D16A419 for ; Fri, 21 Sep 2007 12:07:37 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.ltdomains.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id E986613C4A7 for ; Fri, 21 Sep 2007 12:07:36 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.storspeed.com (209-163-168-124.static.twtelecom.net [209.163.168.124]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l8LBeSZ0084153; Fri, 21 Sep 2007 06:40:29 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <46F3ADAA.6080208@freebsd.org> Date: Fri, 21 Sep 2007 06:40:26 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: "Decibel!" References: <1F219879A7E5C565C96109FF@c-2f56e155.1521-1-64736c12.cust.bredbandsbolaget.se> <57EF86A6-6062-4F1A-959E-41ABABD3F0CF@decibel.org> In-Reply-To: <57EF86A6-6062-4F1A-959E-41ABABD3F0CF@decibel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: freebsd-performance@freebsd.org, Palle Girgensohn , Francisco Reyes Subject: Re: AMD or Intel? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 12:07:37 -0000 Decibel! wrote: > On Sep 13, 2007, at 3:24 PM, Palle Girgensohn wrote: >> --On torsdag, torsdag 13 sep 2007 15.07.17 -0400 Francisco Reyes >> wrote: >> >>> Palle Girgensohn writes: >>> >>>> Now, I hear rumors that AMD is to be preferred over Intel for >>>> performance >>> >>> From what I have read in the past, specially in the postgresql list, it >>> seems the AMD64 cpus do better with Postgresql. Possibly because of >>> better bus architecture. >> >> I think this is not current information; the new woodcrest >> architecture performs mucg better, although this is deduced from this >> thread's discussion... > > Except this thread has largely glossed over the importance of memory > bandwidth, which is exactly the reason why Opterons have been beating > Xeons for several years. Last I'd heard, things were fairly close > between the two, but that would matter on how many cores and physical > CPUs you have. This is still true, even with the latest Intel Cores. For stuff that does massive memory work, AMD's seem to be faster. However, for non-memory intensive applications, the Intel procs are smokin' fast. > It would be good if someone could do a database benchmark for some of > the larger parts. > > Something else worth mentioning... a lot of work is being done to > improve PostgreSQL scalability for larger numbers of CPUs. If you're > looking at anything over 4 cores, I recommend going to 8.3 ASAP. Hmm. Sounds like you know a lot about database stuff (database architect!), maybe you would be a perfect candidate for the benchmark? :) Blue Skies! Eric