Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable.

[jhell]

On 09/03/2010 20:14, David Xu wrote:
> jan.grant at bristol.ac.uk wrote:
>> On Thu, 2 Sep 2010, Andriy Gapon wrote:
>> 
>> 
>>> on 02/09/2010 12:08 jan.grant at bristol.ac.uk said the following:
>>> 
>>>> On Wed, 1 Sep 2010, Ivan Voras wrote:
>>>> 
>>>> 
>>>>> On 09/01/10 15:08, jan.grant at bristol.ac.uk wrote:
>>>>> 
>>>>>> I'm running -STABLE with a kde-derived desktop. This setup
>>>>>> (which is pretty standard) is providing abysmal interactive
>>>>>> performance on an eight-core machine whenever I try to do
>>>>>> anything CPU-intensive (such as building a port).
>>>>>> 
>>>>>> Basically, trying to build anything from ports rapidly
>>>>>> renders everything else so "non-interactive" in the eyes of
>>>>>> the scheduler that, for instance, switching between virtual
>>>>>> desktops (I have six of them in reasonably frequent use)
>>>>>> takes about a minute of painful waiting on redraws to 
>>>>>> complete.
>>>>>> 
>>>>> Are you sure this is about the scheduler or maybe bad X11
>>>>> drivers?
>>>>> 
>>>> Not 100%, but mostly convinced; I've just started looking at
>>>> this. It's my first stab at what might be going on. X11
>>>> performance is usually pretty snappy. There's no paging
>>>> pressure at all.
>>>> 
>>> From my experience: 1. system with Athlon II X2 250 CPU and
>>> onboard AMD graphics - no issues with interaction between
>>> buildworld and GUI with all KDE4 effects enabled (OpenGL). 2.
>>> system with comparable Core2 Duo CPU and onboard Intel graphics 
>>> (G33) - enabling OpenGL desktop effects in KDE4 leads to the
>>> consequences like what you describe.  With all GUI bells and
>>> whistles disabled the system behaves quite like the AMD system.
>>> 
>> 
>> All desktop effects are disabled. The graphics are from an nVidia 
>> GeForce 8500 GT (G86) with the X.org driver. (It's not _just_
>> desktop behaviour that's affected, though: the box runs a number of
>> small headless [interactive] server processes which also appear to
>> get rapidly starved of CPU time.)
>> 
>> The behaviour isn't visible with the 4bsd scheduler; "stuff"
>> generally remains snappy and responsive.
>> 
>> I'll keep poking around and see if I can get to the bottom of it.
>> 
>> 
>> 
>> 
> I think sysctl kern.sched.preempt_thresh is too low, default is only
> 64. I always tune it up to 200 on  my desktop machine which is
> running gnome and other GUI applications, for a heavy GUI deskkop, I
> would tune it up to 224 to get better result.
> 

For reference how did you arrive at 224 for a result ?

-- 

 jhell,v