TTY task group scheduling
gcooper at FreeBSD.org
Sat Nov 20 01:49:58 UTC 2010
On Fri, Nov 19, 2010 at 5:27 PM, Oliver Pinter <oliver.pntr at gmail.com> wrote:
> My desktop running 7-STABLE with 100Hz and NOPREEMPT (it's a 4core SMP system),
> I tested 8-STABLE, but that is not too responsive, the solution is:
> 100Hz NOPREEMPT + kern.sched.preempt_thresh=224
> After this setting, the system is likely responsive as 7-STABLE.
> On 11/19/10, Garrett Cooper <gcooper at freebsd.org> wrote:
>> On Fri, Nov 19, 2010 at 1:10 PM, Oliver Pinter <oliver.pntr at gmail.com>
>>> On 11/18/10, O. Hartmann <ohartman at zedat.fu-berlin.de> wrote:
>>>> On 11/18/10 02:30, grarpamp wrote:
>>>>> Just documenting regarding interactive performance things.
>>>>> This one's from Linux.
>>>> it would be nice to have those improvements in FreeBSD, but I doubt this
>>>> will make it in due time to FreeBSD's kernel.
>> And my one line fix:
>> renice 10 `pidof firefox-bin`
>> Instantly my system is snappier (and in fact my system got really
>> laggy after applying the preempt sysctl that everyone recommended
>> before)... Performance issue with firefox maybe :P? I don't see the
>> point of adding an additional layer to complicate the system (and
>> essentially slow it down) if all you're trying to do is better
>> describe the nice'ing problem, unless this logic is what you want to
>> do strictly for desktop users in PCBSD, etc who may not have the
>> technical wherewithal to accomplish this task.
>> Besides, the Linux kernel has different compile time profiles for
>> different workloads, so maybe it just works better for them because
>> they already have a means for describing that functionality, whereas
>> FreeBSD is more generic.
>> It would be nice to describe this in a document though so people could
>> also decide how to tune the system for themselves and not deal with a
>> patch like what's noted above by the penguin crowd because it will
>> invariably fail under some workloads or conditions (I have yet to see
>> a one-size-fits-all solution in this area).
>> SCHED_ULE improvements though should be looked into if possible,
>> because there are some potential items that could be done to cluster
>> processes together better, maybe.
Ugh. Looks like this was the only machine that I setup recently where
I didn't set kern.hz...
Ok, will retry after building and installing a whole new world *queue
lame Disney music here* and kernel.
Thanks for the obvious reminder...
More information about the freebsd-current