Rene,
Of the uni-processor systems currently that can run Linux, I would not
doubt if 99.9999% percent are uni-cores. It will be probably
3-5 years minimum before the multi-core processors will have any
decent percentage of systems.
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.
Thus, the fallout MIGHT be a uni-processor CFS that would not migrate
tasks between multiple CPUs and as additional processors are brought
online, migration could be enabled, and gang type scheduling, whatever
could be then used.
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..
Mitchell Erblich
------------------------------
Rene Herman wrote:
>
> On 08/06/2007 10:20 PM, Mitchell Erblich wrote:
>
> > Thus, a hybrid schedular approach could be taken
> > that would default to a single uni-processor schedular
>
> What a brilliant idea in a world where buying a non multi core CPU is
> getting to be only somewhat easier than a non SMT one...
>
> 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/
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.
On 08/07/2007 01:35 AM, Rene Herman wrote:
> 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.
(no, that's obviously wrong given embedded volumes, but as stated below,
embedded is fine running non-generic, !CONFIG_SMP kernels).
Rene.