Re: TTY task group scheduling

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>
> wrote:
>> http://lkml.org/lkml/2010/11/16/392
>>
>> 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.
>>>>
>>>> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1
>>>
>>> Well,
>>> 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).
>
> <handwaving>
> 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.
> </handwaving>
>
> Thanks,
> -Garrett
>