Re: SCHED_ULE on desktop system

From: Jeff Roberson <jroberson_at_chesapeake.net>
Date: Sun, 16 Sep 2007 20:26:28 -0700 (PDT)
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.

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"
>
Received on Mon Sep 17 2007 - 01:24:16 UTC

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