Date: Mon, 17 Sep 2007 02:37:28 +0200 From: Kris Kennaway <kris@FreeBSD.org> To: Kevin Oberman <oberman@es.net> Cc: "David E. Thiel" <lx@FreeBSD.org>, freebsd-current@freebsd.org Subject: Re: SCHED_ULE on desktop system Message-ID: <46EDCC48.2090405@FreeBSD.org> In-Reply-To: <20070916225019.B921C4500C@ptavv.es.net> References: <20070916225019.B921C4500C@ptavv.es.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46EDCC48.2090405>