Date: Sun, 26 Dec 2004 02:33:57 -0500 (EST) From: Jeff Roberson <jroberson@chesapeake.net> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern subr_trap.c Message-ID: <20041226023340.F60504@mail.chesapeake.net> In-Reply-To: <20041226023047.R60504@mail.chesapeake.net> References: <200412260730.iBQ7UaDI001958@repoman.freebsd.org> <20041226023047.R60504@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I forgot to mention. This change was made possible by observing thread states with schedgraph.py. :-) On Sun, 26 Dec 2004, Jeff Roberson wrote: > This causes a slight slowdown with sched_ule because ule depends on extra > context switches to help out the load balancer. I'm in the process of > making a slightly more agressive rebalancer at the moment, after which it > will be an improvement on ULE as well. Allowing the thread to continue to > run even though it is not technically the highest priority thread is > acceptable in this case because priority propagation ensures that we are > not running when something as important as an interrupt thread is still > waiting to run. > > On Sun, 26 Dec 2004, Jeff Roberson wrote: > > > jeff 2004-12-26 07:30:36 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/kern subr_trap.c > > Log: > > - Run sched_userret() after thread_userret(). Before, sched_userret() would > > lower the priority of the returning thread to a user priority before > > calling into thread_userret() which would call wakeup() which in turn would > > cause the returning thread to eventually context switch rather than > > completing its slice. Allowing this thread to complete its slice first > > yields a 15% performance improvement in super-smack on my dual opteron with > > 4BSD. > > > > Revision Changes Path > > 1.277 +4 -5 src/sys/kern/subr_trap.c > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041226023340.F60504>