SCHED_ULE on desktop system
Jeff Roberson
jroberson at chesapeake.net
Mon Sep 17 14:14:17 PDT 2007
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?
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"
>
More information about the freebsd-current
mailing list