lkml.org 
[lkml]   [1998]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Cyrix Detection -- NO SMP, please ?????
In <Pine.LNX.3.96.981018115925.22009A-100000@z.ml.org> Gregory Maxwell (linker@z.ml.org) wrote:

GM> My linux is SLLLOOOWWWW.. My linux is SLLLOOOWWWW..

GM> The dists should be shipping two sets of kernels. Both with PPRO opt
GM> turned on and MTRR support. This leaves out the i386. SO? What the hell
GM> are you doing Running RedHat 5.5 w/ a 2.2 kernel on a i386?!? PPro opt
GM> will work on i486+.

I'm not so sure. AFAIK kernel compiled for Pentium (let alone PPro) could do
some nasty things under 486 :-(( There are some difference in paging support...

GM> MTRR support must be on w/ PPRO+ SMP because some MBs dont set MTRRs
GM> correctly on both CPUs..

MTRR should be compatible with 486-optimized kernel :-)

GM> Most people have UP. The install's failure modes should set the kernel to
GM> UP in any case.

Why ? How SMP support could harm in failure mode ? Only if it will prevent
kernel from booting :-))

>> GM> No there should be seperate SMP and UP kernels. Do you think that x86 and
>> GM> Alpha should run from the same kernel binary?
>>
>> This will be great but it's almost impossible to do :-((

GM> :) I know how to do it. You enhance the boot loaded so it can boot a 'fat'
GM> kernel. (i.e. all the ARCHS catted togeather) The same would work for SMP.
GM> I'm not so sure I want 100megs of my HDD eaten up by a fat kernel and fat
GM> modules.

Old BIOS'es does not support more then 1.44" floppy image as "boot image" for
bootable CD's :-((

GM> I understand that you want all non-exp stuff to work. I do too. APM and
GM> SMP are mutually exclusive. There is some alternitive to APM (forget it's
GM> name) that will work with SMP. Can you point out ANY OSes that use SMP and
GM> APM? :)

Hm. Why Linux should not be first such OS ?

>> Why ? Why my SMP box should be powered all time and could not go to sleep when
>> it's not active for long time like UP one ? I'm KNOW that it's a big problem
>> to call APM BIOS from SMP kernel (you should stop second processor first, then
>> make call -- AFAIK it's the only reliable way to do this; since this will
>> require A LOT OF work this is definiteally not 2.2 task if at all). I'm know
>> this as programmer but as user I'm confused: why my UP box could turn power off
>> itself (without me pressing on "BIG RED BUTTON") while my SMP box with the same
>> components except second proc could not ???

GM> I think that that part of APM can be done safely under SMP..

No. You could not call APM BIOS safely under SMP at all :-(( It's possible to
stop second proc and call SMP (in theory) but it's unclear if this is worth
such troubles. And this is not 2.2 issue anyway :-)

>> I know this. But in "real-world" examples this overhead is pretty small! Of
>> course it's not hard to develop special example where such overhead will be
>> problem but in most cases this overhead is not a problem...

GM> It is a big difference.

When ? What kind of work you should do to see more then few per cent's
difference in speed of SMP and UP kernel on UP comp ?

>> Dists should select right kernel automatically in most cases. Windows NT do
>> this for last few years -- why Linux could not do this ? "Joe Average" viewpoint
>> of course :-))

GM> It's possible.

It's not possible if we need to find "correct configurations" out of
1'000'000'000'000'000'000'000'000'000'000+ possible configurations (if we
had only 100 options in kernel -- now we have more then 100 options there and
thus more then 1'000'000'000'000'000'000'000'000'000'000 possible
configurations) -- Earth simple does not enough have resources to do this :-((
We should have few (no more then 5-10 and better only one) which will
fit 99.9% users... With modules usage of course :-))





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.120 / U:0.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site