I released 2.1.30 a few hours ago, after a longish delay. The reason
for the delay is the new SMP code in 2.1.30 - this is the first kernel
that supports (a limited form of) concurrent kernel CPU usage. Rather
than using just one large lock for the whole kernel, 2.1.30 starts to
split the locks into smaller sections. I've been working on getting
that working and stable the last ten days...
Note that the 2.1.30 kernel doesn't actually have very many locks: the
current locks are mainly concerned with interrupt handling and process
scheduling, as those two areas are the most fundamental and any future
locking changes rely on these being stable. As such you shouldn't
expect any huge difference in behaviour - Linux still isn't likely to
scale linearly on anything that spends appeciable amounts of CPU-time in
However, the change is quite fundamental, and I'd ask anybody who is
running Linux/SMP to try out the new kernel if you're at all willing to
test bleeding-edge stuff. I haven't yet much looked into the impact of
the new code on uni-processor machines, but I'd certainly appreciate
comments and potential patches for UP-related issues too...
Final comment: I've been very much in hack mode for the last week,
concentrating on making sure the SMP code is basically sane. As usual,
that means that my email queue hasn't gotten all that much attention,
and if you have a patch that didn't find its way into 2.1.30 it is
probably best to re-send.. Sorry.
The 2.1.30 SMP change fixes the SMP lockup problem (this is the same
problem that had an interim fix in 2.1.29). If you have problems with
your SMP setup tending to silently just lock up under heavy load, this
kernel is definitely worth testing.
Finally - 2.1.30 is likely to break on non-x86 platforms. I hope to get
that fixed soon (our machines from Finland still haven't arrived, so I
can't do alpha development right now, but that should be rectified
On 27 Mar 1997, Linus Torvalds wrote:
> [...] I haven't yet much looked into the impact of
> the new code on uni-processor machines, but I'd certainly appreciate
> comments and potential patches for UP-related issues too...
ksymoops breaks when compiling uniprocessor. spinlocks in sched.c are
declared but unused, this leads to extra 'U' entries at the beginning of
System.map, which in turn confuses ksymoops.
i've put those spinlocks into #ifdef __SMP__, but i think a more correct
solution would be to do something like this:
# define DECLARE_SPINLOCK(name) spinlock_t name
# define DECLARE_SPINLOCK(name)
DECLARE_SPINLOCK( runqueue_lock=SPIN_LOCK_UNLOCKED );
static spinlocks cant be defined this way, is that a problem?