Re: SCHED_ULE on desktop system

From: Jeff Roberson <jroberson_at_chesapeake.net>
Date: Mon, 17 Sep 2007 14:17:09 -0700 (PDT)
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"
>
Received on Mon Sep 17 2007 - 19:14:17 UTC

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