Jeff Roberson wrote: > 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. I explained my problem in http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076450.html. This is a UP system and I have 1GB RAM and top results are shown there. Ganbold > > 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" >> > _______________________________________________ > 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 - 05:29:58 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:17 UTC