Re: Massive performance loss from OS::sleep hack
- From: David Xu <davidxu@xxxxxxxxxxx>
- Date: Mon, 17 Sep 2007 10:34:55 +0800
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
_______________________________________________
freebsd-performance@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscribe@xxxxxxxxxxx"
- References:
- Massive performance loss from OS::sleep hack
- From: Kris Kennaway
- Massive performance loss from OS::sleep hack
- Prev by Date: Re: Massive performance loss from OS::sleep hack
- Next by Date: Re: AMD or Intel?
- Previous by thread: Re: Massive performance loss from OS::sleep hack
- Index(es):
Relevant Pages
|
