Date: Sun, 2 Mar 2008 21:59:58 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Jeff Roberson <jroberson@chesapeake.net> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern sched_ule.c Message-ID: <20080302105958.GF67687@server.vk2pj.dyndns.org> In-Reply-To: <20080301222513.Y920@desktop> References: <200803020821.m228L0Yw042389@repoman.freebsd.org> <20080301222513.Y920@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
--cPi+lWm09sJ+d57q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 01, 2008 at 10:29:50PM -1000, Jeff Roberson wrote: >With these changes ULE is the only scheduler that supports the new cpuset= =20 >api. Excellent work. I didn't expect it to be implemented so quickly. > It succeeds on 4BSD but the scheduler doesn't obey the masks. I don't=20 >presently have a plan to implement it on 4BSD as it will be potentially=20 >very inefficient to search the runq for a compatible thread on every=20 >context switch. I won't object if someone else wants to implement this,= =20 >otherwise I'll make the syscalls return ENOSYS if 4BSD is compiled in. I would prefer to see the project devote available resources to improving ULE - with a view to deprecating 4BSD ASAP - rather than retrofitting new features into 4BSD. IMHO, it's not clear whether requests via the cpuset API should be mandatory or advisory - I believe valid cases can be made for either approach. In the latter case, it would be more reasonable for the cpuset implementation on 4BSD to just be a no-op, rather than failing. >Kris has done some excellent benchmarking as usual. Here you can see the= =20 >improvement in postgres depending on various scheduler debug settings: > >http://people.freebsd.org/~kris/scaling/pgsql-16cpu.png The improvement is quite substantial. Congratulations Jeff. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --cPi+lWm09sJ+d57q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHyoiu/opHv/APuIcRAuhKAJ4/cXLP36hGxqKgBKshyj4dDPerTwCdH9GA nK/6VWjsh20RK3sFAIk2Mdc= =ArkA -----END PGP SIGNATURE----- --cPi+lWm09sJ+d57q--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080302105958.GF67687>