Date: Mon, 15 Nov 2004 12:19:53 +0100 From: fandino <fandino@ng.fadesa.es> To: freebsd-questions@freebsd.org Subject: Re: Scheduling Issues with Multimedia Apps Message-ID: <419890D9.90802@ng.fadesa.es> In-Reply-To: <20041114102640.GC20277@alzatex.com> References: <20041114102640.GC20277@alzatex.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Loren M. Lang wrote: > Certain tasks that have been doing on FreeBSD like installing ports seem > to interrupt my music playing. Particually when portupgrade is > extracting/checksumming and when it is updating the package database. > Now to try and solve this I tried to set xmms to use realtime priority > and made it setuid root. According to top it's running at priority 20 > nice -76 so it seems to be running realtime, but portupgrade can still > interrupt the audio occasionally. I've tried nicing portupgrade before, > but I usually forget, though I'm not even sure if nicing it fixed the > problem. I've had this problem with FreeBSD 4.9 to 5.3 on two > completely different machines. Also I've had to stop distibuted.net > running before because I couldn't play movies with mplayer smoothly. > This was on a P4 3.0 GHz, 1G DDR 400 MHz ram. dnet always runs with a > nice value of 20 which puts it at about priority 131. Why are these > programs able to interrupt my multimedia programs so much. The > multimedia programs don't need to use much CPU time with systems as fast > as these, but they just need to make sure they get X work done in Y > amount of time. If their scheduled apropriately there should be no > conflicts, I've never really had this issues with linux, AFAIK. Is > there any better way to fix this? I recently read an interview which I think is related with you problem, this is a excerpt: Quote: Getting things out from under Giant has improved performance and interactivity. There still remains however the problem of I/O starvation (eg, the system slows to a crawl while extracting large archives). What can be done about that, and are there plans to do something about it? A large part of the problem is that the vnode system grabs Giant and while that happens nothing much else happens. In essence the entire filesystem arena is single-threaded. The phk_bufwork stuff cuts the bottom bit of this: Today when you get down to the filesystem and it decides to read sector number foo from the disk it asks the vnode system to do so, with phk_bufwork it will send the request to GEOM instead which is a bit faster. But getting the vnode layer more multithreaded is a nasty piece of work which we can just keep chipping away at until we get to the end. read the whole interview: http://forums.bsdnexus.com/viewtopic.php?p=2236 Regards
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?419890D9.90802>