Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Oct 2007 22:15:46 +0200
From:      "[LoN]Kamikaze" <LoN_Kamikaze@gmx.de>
To:        josh.carroll@gmail.com
Cc:        Kris Kennaway <kris@freebsd.org>, freebsd-stable@freebsd.org
Subject:   Re: SCHED_4BSD in RELENG_7 disturbs workflow
Message-ID:  <47151BF2.6020103@gmx.de>
In-Reply-To: <8cb6106e0710161309o4658f41fse686b637d96be7f1@mail.gmail.com>
References:  <47150D87.3070804@gmx.de> <47150F82.9060805@FreeBSD.org> <8cb6106e0710161309o4658f41fse686b637d96be7f1@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Josh Carroll wrote:
>> 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
> 

I suspect that the increased performance is stolen from the process with
focus. I don't care much about my calculation being 5% faster if that renders
the machine unusable.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47151BF2.6020103>