On 08/06/2007 11:48 PM, Mitchell Erblich wrote:
Of the uni-processor systems currently that can run Linux, I would not
doubt if 99.9999% percent are uni-cores.
s/can// and I would. s/uni-processor// additionally and I'd assure you it's
untrue. s/uni-cores/non-smt uni-cores/ and I'd do the same.
It will be probably 3-5 years minimum before the multi-core processors
will have any decent percentage of systems.
Which is also approximately the same timeframe in which one might consider
currently developped kernels obsolete for deployment by the way...
And I am not suggesting not supporting them. I am only suggesting is wrt
the schedular, bring the system up with a default schedular, and then
load additional functionality based on the hardware/software requirements
of the system.
But why? First, look at the number of #ifdef CONFIG_SMP in the scheduler
code -- the Linux kernel already has seperate UP/SMP schedulers selected
through CONFIG_SMP. Embedded can certainly use its own !CONFIG_SMP kernels,
for Linux servers SMP is the norm today and for the desktop/home, SMP
probably already _also_ is the norm today, what with multi-core and HT
(which needs different things than real SMP does, but is also certainly not
UP). And if it isn't, it will be tomorrow and stay that way for the
forseeable future.
[ snip ]
IMO, if their is a fault (because of heat, etc) the user would rather
bring up the system in a degraded mode. Same reason applies to... boot
-s..
To what? I don't understand this comment. You are optimizing for the case of
a dead CPU? Why would the user care if he'd be running the most optimal
scheduler for the situation when his box is limping along anyway?
Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
