[suse-sparc] Antwort: Re: [suse-sparc] trying to compile 2.4.16 kernel on Sparc LX ..

From: Thomas Schmid (Thomas.Schmid_at_ascom.ch)
Date: Tue Jun 11 2002 - 08:23:39 CEST

  • Next message: Fredrik Pettai: "SV: [suse-sparc] Boot + Root + Raid + Silo (instead of Lilo)"

    Message-ID: <OF244E208C.9852EF99-ONC1256BD5.00229B04@hasler.ascom.ch>
    From: "Thomas Schmid" <Thomas.Schmid@ascom.ch>
    Date: Tue, 11 Jun 2002 08:23:39 +0200
    Subject: [suse-sparc] Antwort: Re: [suse-sparc] trying to compile 2.4.16 kernel on Sparc LX ..
    

    Hi,

    my 2 euro cents of comment:

    >> I was trying to compile the Kernel and it was crawling to ..
    > Be prepared that kernel compiles will take several hours on this
    machine.
    > It's close to an hour on my dual SM71-SS20 with 256MB - with a SMALL
    kernel

    Affirmative, a compilation of a full SuSE-config'd kernel takes about 6..8
    hours
    on SS LX with 64MB RAM

    About running KDE: I run KDE - it's a bit slow, but not painfully - on a
    SS 5 with
    _96_ MB RAM, on 64MB machines (otther SS5 and LX) it's just not quite
    usable; so on
    32MB machine go with the alternative window managers others on this list
    have mentioned.

    Thomas

    "Ingo T. Storm" <suse-sparc@computerbild.de>
    10.06.02 23:33

     
            An: "suse sparc" <suse-sparc@suse.com>
            Kopie:
            Thema: Re: [suse-sparc] trying to compile 2.4.16 kernel on Sparc LX ..

    > I was trying to compile the Kernel and it was crawling to ..

    Be prepared that kernel compiles will take several hours on this machine.
    It's close to an hour on my dual SM71-SS20 with 256MB - with a SMALL
    kernel
    with only the modules needed on a firewall. Please don't forget you are
    running a beautiful machine - but it has the equivalent horsepower of an
    early Pentium. You'll have to go UltraSparc if you want fast kernel
    builds.

    > Which utility should I use to really see what is going on with
    > memory and swap allocation ? Tried vmstat but that's a bit cryptic to me
    !

    [root@e1k root]# vmstat 10 2
       procs memory swap io system
    cpu
     r b w swpd free buff cache si so bi bo in cs us sy
    id
     0 0 0 2788 14464 23096 15132 0 0 0 0 3 2 0 0
    5
     0 0 0 2788 14460 23096 15132 0 0 0 1 103 5 0 0
    100

    The important columns are:

    "procs r" (unning): Number of processes that are ready to run. Shouldn't
    be
    over 2 (multiplied by #cpus) for a longer period.

    "si/so": swapping in and out. Should be 0 most of the time or you are
    short
    of RAM (yes, there are exceptions, but not for regular use).

    "cpu us"(er): percentage of time spent running your programs
    "cpu sy"(stem): perc. time spent by kernel stuff. Shouldn't be over 10-20%
    for extended periods of time, otherwise you probably have an I/O problem.
    "cpu id"(le): the obvius. Shouldn't be over 5 percent, or you are wasting
    electricity;-)

    top isn't bad for a first glance either:

    try "top i S" (i to ignore idle processes, so you only see the processes
    that actually so s.th., S to show the cumulative time of a process and its
    dead children. This is esp. nice to see how much "make" has been doing
    with
    all the processes it has spawned).

    Sample during a build of wmakerconf on a SparcServer1000 with dual SM61,
    64MB, kernel 2.2.x:

     11:26pm up 5 days, 5:37, 3 users, load average: 1.04, 0.79, 0.39
    41 processes: 39 sleeping, 2 running, 0 zombie, 0 stopped
    CPU0 states: 0.3% user, 2.2% system, 0.0% nice, 96.4% idle
    CPU1 states: 95.1% user, 4.3% system, 0.0% nice, 0.0% idle
    Mem: 60352K av, 58968K used, 1384K free, 12700K shrd, 17612K
    buff
    Swap: 264112K av, 3240K used, 260872K free 26428K
    cached

      PID USER PRI NI SIZE RSS SHARE STAT LC %CPU %MEM CTIME COMMAND
     8401 root 3 0 1196 1196 964 R 0 2.9 1.9 0:19 top
    10729 root 13 0 7896 7896 1900 R 1 99.2 13.0 0:06 cc1

    read: 2CPUs, one at full load (cc1), one 96,4% idle, no memory shortage
    (only 3240K swap in use).

    Apart from that: Nick's guideline on what NOT to run look pretty good to
    me.
    And of course all my figures are estimates from my usage patterns and by
    no
    means scientifically based and proven. As usual, YMMV.

    Ingo

    -- 
    To unsubscribe, e-mail: suse-sparc-unsubscribe@suse.com
    For additional commands, e-mail: suse-sparc-help@suse.com
    

    -- To unsubscribe, e-mail: suse-sparc-unsubscribe@suse.com For additional commands, e-mail: suse-sparc-help@suse.com



    This archive was generated by hypermail 2.1.0 : Tue Jun 11 2002 - 08:24:24 CEST