> The Linux limitation is very much that our file system is not designed to
> provide real time guarantees but to get maximum work done. Irix XFS actually
> has the notion of being able to open a file and reserve bandwidth on it.
My understanding of the problem (in 2.2.x) is that audio I/O goes
through the kernel lock -- when an audio app calls write(),
sys_write() grabs the kernel lock. This means that audio I/O is
single-threaded with all the other things that hold the kernel lock.
Some of those things, e.g., sys_sync(), hold the kernel lock for a
really loooong time. Audio I/O can hold the kernel lock for a really
long time too, BTW -- write can block indefinitely with a really
huge buffer.
The ideal solution is to eliminate the kernel lock. Obviously,
this is hard. (-:
One potential, but ugly, way to work around the problem would be to
make the audio path bypass the lock. Since this is a part of making
the kernel lock less pervasive, it might be worthwhile to do this,
even if it's ugly.
Here's the outline.
1. Define a new flag in struct file. Call it F_NOKLOCK.
(This flag should not be user-visible, so I don't think it
can go in f_flags. But somewhere in struct file, because
that's the toplevel data structure, and the toplevel
routines grab the lock.)
2. sys_write, sys_read, sys_ioctl and some other
routines change this:
lock_kernel();
do_something();
unlock_kernel();
to this:
int lockme = !(file->f_flags & F_NOKLOCK);
if (lockme)
lock_kernel();
do_something();
if (lockme)
unlock_kernel();
3. Sound drivers that are not dependent on the kernel
lock can set F_NOKLOCK.
4. As other kernel modules -- drivers, filesystems,
network protocols, etc. lose their dependencies
on the kernel lock, they set their F_NOKLOCK bits.
The kernel lock gradually fades away.
In order for an audio app to maintain realtime response, it would have
to do its file I/O in a different thread, and it would have to use an
inter-thread communication mechanism that doesn't use the kernel lock.
But those are possible.
Opinions? Comments?
If Alan or Linus encourages me, I'll do it up and mail out a patch.
K<bob>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/