Date: Sat, 15 Sep 2007 21:08:26 +0200 From: Kris Kennaway <kris@FreeBSD.org> To: Daniel Eischen <deischen@freebsd.org> Cc: java@freebsd.org, performance@freebsd.org Subject: Re: Massive performance loss from OS::sleep hack Message-ID: <46EC2DAA.9070602@FreeBSD.org> In-Reply-To: <Pine.GSO.4.64.0709151423080.1406@sea.ntplx.net> References: <46EC1B55.4060202@FreeBSD.org> <Pine.GSO.4.64.0709151423080.1406@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: >> 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? > > It's certainly not a libkse bug, at least with scope process threads > libkse does the right thinng. For scope system threads and all libthr > threads, it probably depends on what scheduler you are using since > it's essentially a __sys_sched_yield(). > > On a side note, I think pthread_yield() is deprecated and not in the > latest POSIX spec. sched_yield() is in the spec and is specified > to account for behavior in a threaded environment. Yeah, libthr's pthread_yield just calls sched_yield. Anyway, it seems to me that the decision of what thread to run next is a scheduler decision, and if it is inappropriate for some reason for a scheduler to possibly choose to reschedule the same thread that just yielded, this is something that should be addressed in the scheduler rather than by adding hacks to the application. Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46EC2DAA.9070602>