Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: My 66000 and High word facility
Date: Tue, 20 Aug 2024 11:59:31 +0300
Organization: A noiseless patient Spider
Lines: 43
Message-ID: <20240820115931.00000da8@yahoo.com>
References: <v98asi$rulo$1@dont-email.me>
	<38055f09c5d32ab77b9e3f1c7b979fb4@www.novabbs.org>
	<v991kh$vu8g$1@dont-email.me>
	<2024Aug11.163333@mips.complang.tuwien.ac.at>
	<v9b57p$2rkrq$1@dont-email.me>
	<v9brm4$33kmd$1@dont-email.me>
	<e369e386b23628e5388e95b5a92af62d@www.novabbs.org>
	<v9jij9$lk6a$1@dont-email.me>
	<v9jjjn$lofu$1@dont-email.me>
	<v9k38n$rg2a$1@dont-email.me>
	<v9mklt$1air0$1@dont-email.me>
	<1bf2c13fc41cf8aeca4a746052c03ce3@www.novabbs.org>
	<v9oqjo$1k775$1@dont-email.me>
	<cfa0a9c4bda9421fee8ce512bdcd58bf@www.novabbs.org>
	<v9r2s7$21r0k$1@dont-email.me>
	<jwvjzgcsdqs.fsf-monnier+comp.arch@gnu.org>
	<fe800780d11f7aeb36c387efeb6f1f56@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Tue, 20 Aug 2024 10:58:53 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f207901cceb8e35a1b6ac4acbd56b70b";
	logging-data="2954274"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+D/8SIeeWdRLdk18VxVmDXmCxwW/14Oe4="
Cancel-Lock: sha1:WFy4hhlZqV+ynpf42AEs6yGdE5o=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 3249

On Mon, 19 Aug 2024 18:22:27 +0000
mitchalsup@aol.com (MitchAlsup1) wrote:

> On Mon, 19 Aug 2024 16:05:22 +0000, Stefan Monnier wrote:
>=20
> >> Task swapping time is way down in the noise. It=E2=80=99s reloading th=
e L1
> >> and L2
> >> cache that swamps the time. 64 registers is nothing compared to
> >> 32k or megabytes. =20
> >
> > Depends on the kind of swap.  If you're thinking of time-sharing
> > preemption, then indeed context switch time is not important. =20
>=20
> > But when considering communication between processes, then very fast
> > context switch times allow for finer grain divisions, like
> > micro-kernels. =20
>=20
> MicroKernels failed due to the excessive overhead of context
> switching. Whether is was control delivery delay, TLB reloads, Cache
> reloads, register file loads and stores, ... it doesn't really mater
> as each delay adds up. When there is too much delay the system is
> sluggish and unacceptable en-the-large.
>

I don't believe that failure of uKernels to take over the world of
OSes is related to the factors, you mentioned.
It failed because relatively to monolithic kernel it is less convenient
way to structure the OS software. Various parts of the OS are
more dependent on each other logically, esp. in read-only manner, than
proponents of uKernels are admitting. Every change takes more
developer's time and causes touching more places in code than with
monolithic.

> > Historically, these things have never really materialized,
> > admittedly. =20
>=20
> Pigs don't win the 100 yard dash at the Olympics, either.
>=20
> >
> >         Stefan =20