[LUGA] Mit freundlicher Unterstützung von:

Mail Thread Index

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lll]: SMP update: 2.1.30 (fwd)

Forwarded message:
>From owner-lll@radawana.cg.tuwien.ac.at Mon Mar 31 02:11:48 MET 1997
From: Alexander Terczka <alex@terz.priv.at>
Message-Id: <199703310005.CAA06352@a486.terz.ins.at>
Subject: [lll]: SMP update: 2.1.30 (fwd)
To: lll@ins.at
Date: Mon, 31 Mar 1997 02:05:09 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-lll@radawana.cg.tuwien.ac.at
Precedence: bulk

Forwarded message:
>From owner-linux-kernel-outgoing@vger.rutgers.edu Fri Mar 28 01:42:50 1997
To: submit-linux-dev-kernel@ratatosk.yggdrasil.com
Path: torvalds
From: torvalds@transmeta.com (Linus Torvalds)
Newsgroups: linux.dev.kernel
Subject: SMP update: 2.1.30
Date: 	27 Mar 1997 05:19:29 GMT
Organization: Transmeta Corporation, Santa Clara, CA
Lines: 42
Message-ID: <5hd011$kuc$1@palladium.transmeta.com>
NNTP-Posting-Host: penguin.transmeta.com
X-Submitted-Via: news@ratatosk.yggdrasil.com (linux.* gateway)
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk

[ this may show up multiple times, I'm a klutz ]

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
kernel mode. 

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



alex@mail.at               http://www.terz.priv.at/alex/


Schreib an die Liste unter: lll@radawana.cg.tuwien.ac.at
Bei Problemen schreib an:   MajorDomo@radawana.cg.tuwien.ac.at help im BODY!
Archiv:                     http://radawana.cg.tuwien.ac.at/mail-archives/lll

                        Michael P. Demelbauer
          WSR (Wirtschafts- und Sozialwissenschaftliches Rechenzentrum)	
			LUGA (Linux User Group Austria)
	       Past performance is no guarantee for future results.

powered by LINUX the choice of a gnu generation
linux user group austria;
Letzte Änderung:
September 2010