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.981018023233.20378A-100000@z.ml.org> Gregory Maxwell (linker@z.ml.org) wrote:
GM> On Sun, 18 Oct 1998, Khimenko Victor wrote:

>> SMP=1 commented out ? No multicasting with eepro100 ???? What a hell ? SUCH
>> RECOMENDATION IS NOT ACCEPTABLE for 2.2 kernel! Reason ? 2.2 kernel SHOULD
>> work for AT LEAST 99.9% peoples in precompiled binary-only version with all
>> needed capabilities !!!

GM> First off, before you get all hot and bothered: SMP=1 SHOULD BE OFF BY
GM> DEFAULT!. No one SHOULD be running a SMP kernel on a non SMP box! Yes, it
GM> should not lockup.. But it's performance should be less. It should be no
GM> problem for a dist to ship two sets of kernels and modules, and a util to
GM> pick the right one.

Performance issue is completely other story. Do you have util which is able to
find existence of second CPU when UP kernel is loaded ? Otherwise we should
use SMP kernel for installation CD (bootable of course :-) and this CD must
work for MOST users.

GM> It would be nice if a kernel could work optimally on SMP and UP. This is
GM> not possible however, without such monstrosities as self modifying code.

No, no, no. Not self modifying code! But we talk about different things.
My words: "it should work "out of box" for [almost] all users [not optimally,
of course]". Your answer: "it's [almost] not possible to create version which
will work OPTIMALLY "out of box" for [almost] all users". This is other story.
If you want performance you should recompile kernel with pentium or ppro
optimisation for start :-)) Since in most distributions kernel is compiled with
386 optimisiation to ensure compatibility for example.

>> It's Ok for development kernel to have comment "this feature will not work
>> with that other feature enabled" since
>> 1. It's development kernel -- why you think it will work at all ?
>> 2. Most users will compile development kernel for her own configuration.

GM> Yep.

>> For STABLE kernel situation when all NON-EXPERIMENTAL features are turned
>> on SHOULD produce kernel which will work for 99.9% peoples since this kernel
>> will be included in distributions and peoples SHOULD BE able to install
>> Linux "in full glory" WITHOUT kernel recompilation (I think that more then
>> half Linux users does not know how to recompile kernel just now and per cent
>> of such "dumb" users will grow in future). That's why modules was introduced
>> in 1.3 & 2.0 AFAIK. To avoid mess of 1.2.x-based distributions where was few
>> tens of different precompiled kernels :-(( 2.2 SHOULD NOT return that times!
>> Of course we could declare SMP and multicasting as experimental features but
>> what a gosh: SMP and multicasting are STILL EXPERIMENTAL ???? After few years
>> of development and great effort of Linus himself in SMP area ? Something is
>> REALLY wrong here. IMHO anyway.

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> SMP and UP are DIFFERNT BEASTS.

Gm. Not such different beasts from "Joe Average" viewpoint. Development kernels
are for developers, stable kernel are for "Joe Average"'s who is not sure how
many proccessors installed in comp, which proccessor type is installed there and
not aware about VideoCard type and Monitor refresh rates. Yes, Linux is not
ready for completely dumb users and will not be ready for them in near future
but this is does not mean that such thing must not be considered as long-terms
goal (one of them and not most important -- it's better to have reliable system
then "easy to use" unreliable system but when system could be simplified
WITHOUT loss of stabily this should be done).

GM> Multicasting is only an issue with one driver (AFAIK) and is probably the
GM> result of the kludgery required to make multicast work on that card. How
GM> many places do use ethernet multicast? I do agree that it should be fixed,
GM> and they ARE working on it.

There are also IPv6 stuff involved :-)) Of course this is not a problem at all
since IPv6 is (and should be) experimetntal stuff just now. You missed my point:
all NON-EXPERIMETANTAL features of stable kernel must work when all are
activated (except when two features are REALLY inherently mutually exclusive).
Of course errors possible and when two not inherently mutually exlusive features
could not be turned on at the same time it's not end of the world nor end of the
linux but it's BUG, not normal behaviour!

>> P.S. The same is about APM stuff: APM stuff SHOULD work with SMP enabled on
>> when there are really only one processor installed. Unfortunatelly looks like
>> a 2.3 stuff -- to many places to change :-(( But when SMP-enabled kernel could
>> not even START on UP comp -- that's other story. This should be avoided for
>> AT LEAST 99.9% of computers.

GM> No it shouldn't. You shouldn't be using APM with a SMP kernel.

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> You shouldn't be using a SMP kernel on a UP box. SMP adds a lot of overhead
GM> and it's impossible to have a optimum UP (which most systems are) with a
GM> SMP kernel without self-modifying code.

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> If downgrades wern't a consideration I'd be yelling to make SMP kernels
GM> refuse to boot on UP systems. I still think there should be a BIG notice
GM> that you shouldn't use a SMP kernel on a UP system...

GM> The dists can simply use a setup command to pick SMP or UP..

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 :-))

P.S. Most readers of this mailing list are programmers and as such often could
not understood "Joe Averages" who is wondering why his SMP box could not be
turned off via mouse-click on button "Turn Off" on screen while UP box could.
I'm happy with installation of Windows98 on my home comp. All hardware detection
was done automatically. I'm was NOT asked ANY questions about my hardware at all!
That's should be long-term goal. Of course it's better to have questions about
hardware then "magic instructions" like the following: "on IBM Aptiva at school
you should install Ethernet card via "Network" item in Control Panel and not
via "Add new hardware wizard"; otherwise computer will be unable to see other
computers in LAN" (I'm not joking -- it's REAL instruction; it's working while
I'm found that even more reliable way to solve problem was to turn off PnP
on that EtherJet card and after that you could use both "Network" icon and
"Add new hardware wizard" icon without troubles: by unknown reason after adding
EtherJet card via "Add new hardware wizard" EtherJet card is setuped for IRQ5
and when setuped via "Netword" it's setuped for IRQ10 -- why it's work reliable
on IRQ10 but not on IRQ5 is unclear but when PnP is turned off Windows95 could
not change IRQ and EtherJet works reliable in all cases on all 10 Aptivas).




-
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:1.498 / U:0.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site