[lkml]   [1998]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Cyrix Detection -- NO SMP, please ?????
    In <> Gregory Maxwell ( 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. 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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:45    [W:0.029 / U:3.864 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site