On Thu, Nov 18, 2010 at 3:12 PM, Steve Kargl <sgk_at_troutmask.apl.washington.edu> wrote: > On Thu, Nov 18, 2010 at 10:59:43PM +0000, Alexander Best wrote: >> >> well i did exactly what they did in the video. watch a 1080p video and move >> the output window around while compiling the kernel. >> > > It is trivial to bring ULE to its knees. If you > have N cores then all you need is N+1 cpu intensive > task. The issue has been known for a few years. <off-topic> I/O intensive tasks don't help either though. Things tend to get choppy whenever I'm doing something like update from svn and doing something a bit more interactive like use firefox (and scroll... for instance gmail seems to be a pig in this area -- heh), vlc is a little less painful, etc. I wonder if the issue isn't necessarily tasks but more or less locking. firefox uses a lot of threads and file based mutexes according to what I've seen with top and ps (please correct me if I'm wrong). firefox also has a tendency with the nvidia-driver (I know... blobs are bad) to produce funky artifacts on the screen (again, when scrolling on gmail, dealing with flash, etc) or certain bits don't redraw properly (text when scrolling ends up ghosting on multiple lines until I force a redraw with the cursor or by scrolling back over that section of text). I'm sure there are a lot of performance issues within FreeBSD and opensource desktop software that needs to be properly worked out on a case by case basis, so I think that writing everything off as awesome and working better with one magic patch is unlikely. Besides, Linux has a more complicated scheduler than FreeBSD does. </off-topic> Thanks, -GarrettReceived on Thu Nov 18 2010 - 22:37:05 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:09 UTC