Scheduling Issues with Multimedia Apps

[fandino]

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