SCHED_ULE on desktop system

Jeff Roberson jroberson at chesapeake.net
Tue Sep 18 00:42:15 PDT 2007


On Mon, 17 Sep 2007, Marcus Reid wrote:

> On Sun, Sep 16, 2007 at 10:19:32AM +0400, Roman Bogorodskiy wrote:
>> Hello,
>>
>> 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 find SCHED_ULE to provide much better interactivity than SCHED_BSD on
> my desktop.  Normally, I can have a couple of compiles and a bunch of
> other stuff going on in the background and I can't even feel it, and
> I'm on a UP p4.  I can, however, reproduce what you're talking about.
> It's always something graphically intensive that gets it going, and it
> only happens when there's a couple of compiles running in the background.
> I tried to trigger it for hours doing a ton of stuff non-graphical,
> including running a couple of jobs that made it go a gig into swap.
> It handled everything nicely.  However, every time I do something like
> start an opengl app and drag it around or start xlock, with compiles
> in the background, things get very stuttery.  After closing the offending
> app, it continues to be like that for a while, and eventually corrects
> itself and goes back to normal.
>

Marcus,

What has happened is that you have run an x application that is so 
expensive we no longer consider it interactive.  Unfortunately, due to the 
nature of the x server architecture, much of the compute time is spent in 
x11 rather than the offending application.  There really isn't anything to 
be done in this case other than mark X as real-time.  You can try to tune 
up the interactivity heuristic limit by setting kern.sched.interact to a 
higher value.  This will help with short term bursts of x server cpu 
utilization, however, sustained, expensive x windows processing will 
always trigger poorer interactive behavior.

Thanks,
Jeff


> I suspected xorg was maybe blocking on some writes to something but
> looking at the kdump of xorg didn't reveal anything to me.
>
>> However, when I switch to SCHED_4BSD, system's reaction time gets lower
>> and I even can watch a movie with mplayer when compiling something.
>
> I haven't tried SCHED_4BSD yet.  I'll have more time tomorrow.
>
> Marcus
> _______________________________________________
> 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