> 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@FreeBSD.org>
>>>> Sender:
owner-freebsd-current@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.
