From: "David S. Miller" <davem@redhat.com>
To: andrew.grover@intel.com
Cc: riel@conectiva.com.br, linux-kernel@vger.kernel.org, _deepfire@mail.ru
Subject: Re: lilo vs other OS bootloaders was: FreeBSD makes progress
Date: Tue, 04 Sep 2001 18:51:23 -0700 (PDT) [thread overview]
Message-ID: <20010904.185123.26276785.davem@redhat.com> (raw)
In-Reply-To: <4148FEAAD879D311AC5700A0C969E89006CDE0E2@orsmsx35.jf.intel.com>
In-Reply-To: <4148FEAAD879D311AC5700A0C969E89006CDE0E2@orsmsx35.jf.intel.com>
From: "Grover, Andrew" <andrew.grover@intel.com>
Date: Tue, 4 Sep 2001 14:52:17 -0700
I'm not advocating anything similar for Linux, I'm just saying it's an
interesting thought experiment - what if the SMP-ness of a machine was
abstracted from the kernel proper? How much of the kernel really cares, or
really *should* care about SMP/UP?
Every spinlock :-) You'd have to either accept their overhead, or have
some way to nop out the instructions on uniprocessor boots. There
would still be the space overhead after such code patching.
I remember the Digital UNIX folks did something interesting in this
area. There should be a paper online somewhere.
Later,
David S. Miller
davem@redhat.com
next prev parent reply other threads:[~2001-09-05 1:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-04 21:52 lilo vs other OS bootloaders was: FreeBSD makes progress Grover, Andrew
2001-09-05 1:51 ` David S. Miller [this message]
2001-09-05 8:03 ` Helge Hafting
2001-09-05 14:26 ` Horst von Brand
2001-09-11 22:48 ` Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
2001-09-05 21:18 Grover, Andrew
2001-09-05 22:11 ` Alan Cox
2001-09-05 22:13 ` Tim Hockin
2001-09-01 14:55 Samium Gromoff
2001-09-01 12:03 ` Peter Wächtler
2001-09-01 12:39 ` Alan Cox
2001-09-01 14:10 ` Rik van Riel
2001-08-31 21:49 Grover, Andrew
2001-08-31 22:40 ` Andreas Dilger
2001-08-31 22:50 ` Alan Cox
2001-09-01 15:50 ` Jamie Lokier
2001-09-08 17:55 ` Eric W. Biederman
2001-09-08 18:55 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010904.185123.26276785.davem@redhat.com \
--to=davem@redhat.com \
--cc=_deepfire@mail.ru \
--cc=andrew.grover@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@conectiva.com.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.