Date: Tue, 16 Oct 2007 16:09:55 -0400 From: "Josh Carroll" <josh.carroll@gmail.com> To: "Kris Kennaway" <kris@freebsd.org> Cc: "\[LoN\]Kamikaze" <LoN_Kamikaze@gmx.de>, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SCHED_4BSD in RELENG_7 disturbs workflow Message-ID: <8cb6106e0710161309o4658f41fse686b637d96be7f1@mail.gmail.com> In-Reply-To: <47150F82.9060805@FreeBSD.org> References: <47150D87.3070804@gmx.de> <47150F82.9060805@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Not to say that any problems that might have developed with SCHED_4BSD > should not be fixed, but you should give SCHED_ULE a try since it brings > benefits even for single CPU systems (e.g. better interactive response). For my particular work load, 4BSD is actually faster than ULE in RELENG_7. Specifically, on a Q6600 running ffmpeg -threads 8 to transcode some H.264 video, 4BSD is about 5% faster. I took a sample video and transcoded the first 120 seconds of it, and here are the results (including a control from 6.2-RELEASE-p7/4BSD scheduler): releng_6_2 (4BSD) 1:32.39 releng_7 (4BSD) 1:32.44 releng_7 (ULE) 1:37.15 This is obviously a different scenario from MySQL. So perhaps ULE isn't as well tuned for cases like ffmpeg? Josh
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8cb6106e0710161309o4658f41fse686b637d96be7f1>