lkml.org 
[lkml]   [1998]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Cyrix Detection -- NO SMP, please ?????

    > 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.

    It would probably to possible to port the kernels CPU detection routienes
    to 16bit code and put them in lilo so that you could to config it to run
    the right kernel.

    Even if porting to 16bit is too tough it should be trivial to port it to
    userspace so an install util (or later, a reconfig util) can pick the
    right one.

    > 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.

    My linux is SLLLOOOWWWW.. My linux is SLLLOOOWWWW..

    The dists should be shipping two sets of kernels. Both with PPRO opt
    turned on and MTRR support. This leaves out the i386. SO? What the hell
    are you doing Running RedHat 5.5 w/ a 2.2 kernel on a i386?!? PPro opt
    will work on i486+. MTRR support must be on w/ PPRO+ SMP because some MBs
    dont set MTRRs correctly on both CPUs..

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

    I see only one advantage of booting the install disk with a SMP kernel:

    Zero reboot install. What you say? It cant be done? But it can.. You use
    the same kernel on the boot disk as the mail system and you act as if the
    whole install was just an initrd.. I'm dieing for RH to do this on their
    installs: Can you imagine it.. "My new NT5 only required 3 reboots to be
    configured as a Webserver. HA My RH Linux 5.5 needed ZERO".

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

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

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

    Well if Joe Average can't get it then at least we can give him lightling
    fast UP. If I refused to understand the difference between leded and
    unleaded fule, should I still expect my car to work? We can make it as
    simple as possible but no more. While I agree that SMP on UP should work,
    it should only be there for emergency situations. It should not be the
    norm and it should put a big warning up at boot.

    > 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!

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

    > 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 ???

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

    > 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...

    It is a big difference.

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

    It's possible.



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