Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Sep 2007 00:44:52 -0700 (PDT)
From:      Jeff Roberson <jroberson@chesapeake.net>
To:        Marcus Reid <marcus@blazingdot.com>
Cc:        freebsd-current@freebsd.org, Roman Bogorodskiy <novel@freebsd.org>
Subject:   Re: SCHED_ULE on desktop system
Message-ID:  <20070918004027.G558@10.0.0.1>
In-Reply-To: <20070918061806.GA85425@blazingdot.com>
References:  <20070916061932.GA93480@underworld.novel.ru> <20070918061806.GA85425@blazingdot.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070918004027.G558>