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

[David Xu]

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.

Regards,
David Xu