Re: SCHED_ULE on desktop system

From: Ganbold <ganbold_at_micom.mng.net>
Date: Wed, 19 Sep 2007 10:04:49 +0800
Jeff Roberson wrote:
>
> On Mon, 17 Sep 2007, Ganbold wrote:
>
>> Jeff Roberson wrote:
>>> On Mon, 17 Sep 2007, Kris Kennaway wrote:
>>>
>>>> Kevin Oberman wrote:
>>>>>> Date: Sun, 16 Sep 2007 14:47:54 -0700
>>>>>> From: "David E. Thiel" <lx_at_FreeBSD.org>
>>>>>> Sender: owner-freebsd-current_at_freebsd.org
>>>>>>
>>>>>> On Sun, Sep 16, 2007 at 12:58:33AM -0700, vehemens wrote:
>>>>>>> On Saturday 15 September 2007 11:19:32 pm Roman Bogorodskiy wrote:
>>>>>>>> I'm curious if SCHED_ULE is designed to be used on a desktop 
>>>>>>>> system. I'm
>>>>>>>> running -CURRENT at home and tried to use SCHED_ULE for some 
>>>>>>>> time. It
>>>>>>>> works alright while the load is not very high. But once I start
>>>>>>>> compiling something (running 'make buildworld' or 'portupgrade 
>>>>>>>> -a' for
>>>>>>>> example), the machine comes almost unusable - X11's windows 
>>>>>>>> takes a lot
>>>>>>>> of time to redraw, changing virtual desktop in window manager 
>>>>>>>> may take
>>>>>>>> a several seconds. And it's nearly impossible to watch some 
>>>>>>>> movie with
>>>>>>>> mplayer.
>>>>>>> I also see something similar running -CURRENT with SCHED_4BSD,
>>>>>>> but it shows up with X/gnome.  Remote logins are still responsive
>>>>>>> and running X/twm works fine.
>>>>>> In my experience, both 4BSD and ULE are unresponsive on the desktop
>>>>>> in -CURRENT, with ULE being somewhat worse. Compiling an application
>>>>>> causes the mouse to be jerky, windows to draw slowly, audio to start
>>>>>> skipping, and occasionally the whole desktop freezes for a minute at
>>>>>> a time (with ULE only). This is with INVARIANTS and all the 
>>>>>> debugging
>>>>>> kernel options disabled and malloc debugging turned off. I'll 
>>>>>> give running without PREEMPTION with 4BSD and the ULE patch a shot,
>>>>>> but in its stock form, -CURRENT is definitely worse than -STABLE 
>>>>>> on the
>>>>>> desktop for me in a UP configuration. Up till now, I've been working
>>>>>> around it manually by juggling with rtprio.
>>>>>>
>>>>>> If it's of any use, dmesg is at:
>>>>>>
>>>>>> http://redundancy.redundancy.org/dmesg.txt
>>>>>
>>>>> I have been seeing this for quite some time and, while the 
>>>>> scheduler may
>>>>> make a bit of difference, I suspect pager issues. As long as I have
>>>>> available memory, interactivity is fine. If I run a big build and 
>>>>> I see
>>>>> swap file use, things slow to a crawl. I see very slow re-draws of 
>>>>> the
>>>>> screen and general lack of responsiveness.
>>>>>
>>>>> I run gkrellm and can tell at a glance when swap usage starts to
>>>>> increase. The linkage is clear and not terribly surprising. It may be
>>>>> that you need to add a bit more RAM.
>>>>
>>>> Yes, not surprising in the least.  When your system touches swap, 
>>>> performance will drop to a tiny fraction of its normal performance. 
>>>> Depending on your disk this could be 1% or lower.  Anyone who is 
>>>> seeing poor interactive performance needs to rule this out as the 
>>>> cause.
>>>
>>> Ah, I think I know why people are reporting worse problems with 
>>> ULE.  ULE is not properly accounting swtime so different threads are 
>>> being chosen for swapout with ULE and 4BSD.  My test systems all 
>>> have more than enough memory to do parallel buildworlds without 
>>> swapping.  This is likely why I haven't run into this.
>>>
>>> I really need to fix p_swtime with ULE.  Could the people reporting 
>>> bad behavior please verify whether or not you're seeing swapping 
>>> activity? Even just looking for swap used in top will help me verify 
>>> that this is the problem.
>>
>> I explained my problem in 
>> http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076450.html. 
>>
>> This is a UP system and I  have 1GB  RAM and top results are shown 
>> there.
>
> Ganbold,
>
> Thank you for your report.  I just sent a follow-up mail to current 
> with a patch that addresses this issue.  Can you test and report back?

Sorry Jeff, I'm away from office and probably can't test this patch 
until beginning of October :(
But as long as I get a chance I will test it.

thanks a lot,

Ganbold
>
> Thanks!
> Jeff
>
>>
>>
>> Ganbold
>>
>>>
>>> Thanks,
>>> Jeff
>>>
>>>
>>>>
>>>> Kris
>>>> _______________________________________________
>>>> freebsd-current_at_freebsd.org mailing list
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>> To unsubscribe, send any mail to 
>>>> "freebsd-current-unsubscribe_at_freebsd.org"
>>>>
>>> _______________________________________________
>>> freebsd-current_at_freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to 
>>> "freebsd-current-unsubscribe_at_freebsd.org"
>>>
>>>
>>>
>>
>> _______________________________________________
>> freebsd-current_at_freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to 
>> "freebsd-current-unsubscribe_at_freebsd.org"
>>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to 
> "freebsd-current-unsubscribe_at_freebsd.org"
>
>
>
Received on Wed Sep 19 2007 - 00:06:24 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:17 UTC