Subject: Re: [linux-audio-dev] State of kernel?
From: Roger Larsson (roger.larsson_AT_norran.net)
Date: Tue Oct 10 2000 - 22:08:15 EEST
Hi,
As Paul says his description is simplified
for the interested this has a little more detail.
Paul Barton-Davis wrote:
>
> 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.
>
It is actually worse :-(
To prevent this a new thread is not started as long as you run into
kernel space,
with or without locks...
Locks, like BKL, are actually only used in a multi processor system -
the first
approach was the BKL that enforced the UP rule - only one thread in
kernel at
one time.
> 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).
>
Since a BKL has _severe_ performance problems much work has been put
into
more fine-grained locking - the more processes the more likely that
several
of them likes to run kernel code at the same time.
To improve SMP performance you want many locks that protects small parts
each but at the same time all necessary.
At this point you might realize that the rule not to schedule inside the
kernel can be removed - it is suddenly safe, as long as you are not
holding any locks. (Montavista has released a patch that does this for
2.4-testX, something like it will probably be included in next
development
branch 2.4)
Conclusion: finer grained locking will improve both SMP performance for
computers with lots of processors and make low latency kernels possible.
Note: you need to add an extra check for if scheduling is required when
you leave a lock - some do not want this overhead and the kernel will
probably end up with several compilation options.
SMP / UP
standard / preemtive
with the combinations of SMP-standard, UP-preemtive, UP-standard being
the most common.
[deleted stuff]
> 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
/RogerL
PS
Robert jobbar du i Skellefteċ, Uppsala eller Stockholm :-)
DS
-- Home page: http://www.norran.net/nra02596/
This archive was generated by hypermail 2b28 : Tue Oct 10 2000 - 23:50:22 EEST