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