Subject: Re: [linux-audio-dev] State of kernel?
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Tue Oct 10 2000 - 17:45:39 EEST
In message <39E2B97E.B1946701_AT_dataductus.se>you write:
>Pardon my insufficient knowledge, and this isn't exactly the right forum, but
>anyway:
>
><stuff omitted>
>
>> * some work appears to be underway to get the kernel to be
>> fully preemptable, which would solve most of the problems.
>
>Is there an easy way to explain how this differs from the way the kernel works
>now, and also how this improves the situation?
At the moment, when a process enters the kernel (typically by making a
system call), it needs to be able operate on certain kernel data
structures safely. for example, if it is deleting a file (via unlink(2)),
it must be able to modify the in-memory representations of a directory
structure safely. if another process were to, say, create a file in
that same directory in the middle of the unlink, and both processes
were messing around with the data structures at the same time, a complete mess could
result.
How could 2 processes end up doing this at the same time ? Well, as
one example, suppose that the timeslice for the first process was just
about expired (recall: most Unix-like OS's give a process a certain
amount of time, typically around several hundred msecs). In a *totally
broken* OS, a timer interrrupt arrives, the kernel scheduler looks
around, and decides that its time to stop the first process, and allow
the second one to run. If this happened at the "wrong time", trouble
could arise. We call this process by which we switch from one process
to another because of an interrupt (typically) "preemption". The old
process has been "preempted" in favor of the new one.
So, to protect kernel data structures, there are locks that a process
must acquire (well, by convention; nothing can enforce this) before it
modifies the data structures. Ideally, there would be one lock per
data structure, so that only two processes (threads, actually) that
want to modify the same data structure have to compete for the lock.
Alas, in many cases, the kernel still uses
the so-called "Big Kernel Lock" to protect many different data
structures. The result is that a process which is modifying data
structure A can block another process which is modifying data
structure B, even though A and B have no connection other than sharing
the same lock.
Slowly, the kernel is moving toward much "finer-grained" locks, where
there is a lock for just particular data structures, or classes of
data structures. When this scheme is in use, its still not possible
for one process to acquire that lock, but if it doesn't need it
(because its not operating on those particular kernel data
structures), then it can still run in kernel mode (and perhaps even
return to user space).
So, this is big improvement, because only processes that are genuinely
needing to work on the same data will block each other from
running. As a result, the chances greatly improve that when a timer or
other interrupt results in a process being selected to run, it really
will be able to execute, rather than just block immediately as it
waits for the lock.
Now, a "fully preemptable" kernel is not actually very likely, because
total preemption (that is, any process can start running regardless of
what any other process is/was doing) requires lock-free data
structures in the kernel, and this is mostly a CS research area at
this time. However, a system of fine-grained locks and the removal of
the "Big Kernel Lock" will result in a situation where, when an
external event (e.g. audio data being ready for delivery to a process)
causes a process to be runnable, it really can run more or less
immediately. Of course, if there are two processes playing around with
the audio interface, its still possible that one may hold a lock that
the other one needs. But in general, our device drivers (ALSA in
particular) and our applications don't lead to this situation occuring
much at all. So this system will allow a SCHED_FIFO process/thread to
start running as soon as the audio h/w interrupt says it should.
To contrast that with the current situation: if another process/thread
holds the BKL, it is (often) not possible to start the SCHED_FIFO
thread until the BKL is released. Yikes :)
This may not have been "simple", and it may not even be entirely
correct because I've tried to simplify a number of things and also
because the kernel is very much in transition with a lot of this
stuff. But hopefully it gives you some idea of whats going on when we
talk about a "preemptable kernel".
--p
This archive was generated by hypermail 2b28 : Tue Oct 10 2000 - 18:16:56 EEST