Messages in this thread | | | From | "Khimenko Victor" <> | Date | Sun, 18 Oct 1998 14:09:05 +0400 (MSD) | Subject | Re: 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/
| |