...making Linux just a little more fun!

Mailbag

This month's answers created by:

[ Anderson Silva, Henry Grebler, Mulyadi Santosa, Mike Orr (Sluggo) ]
...and you, our readers!

Our Mailbag


SFLC vs. Westinghouse (Busybox GPL violation)

Jimmy O'Regan [joregan at gmail.com]


Thu, 5 Aug 2010 16:15:39 +0100

http://www.theregister.co.uk/2010/08/04/gpl_violation_westinghouse/

"It's the first time a US court has awarded an injunction ordering a GPL violator to permanently stop distribution of out-of-compliance GPL'd software."

http://sfconservancy.org/news/2010/aug/03/busybox-gpl/ http://www.ebb.org/bkuhn/blog/2010/08/03/more-gpl-success.html

-- 
<Leftmost> jimregan, that's because deep inside you, you are evil.
<Leftmost> Also not-so-deep inside you.


Load average vs CPUs

Mike Orr [sluggoster at gmail.com]


Mon, 23 Aug 2010 13:15:26 -0700

Hello Answer Gang. I was raised to believe that the load average reported by 'uptime' and 'top' should not go above 1.0 except for short-term transitory cases, and if it persistently goes to 2 or 3 then either you seriously need more hardware or you're trying to run too much. But recently I heard that the target number is actually equal to the number of CPUs. My server has 4 CPUs according to /proc/cpuinfo, so does that mean I should let the load average go up to 4 before being concerned?

In fact, my load average has not been that high. It was 1.5 or 1.7 when I noticed the server bogging down noticeably, and that was probably because of a large backup rsync, and a webapp that was being unusually memory-grubbing. Still, my basic question remains, is 1.5 or 2 normal for a multi-CPU system?

One other issue is, I'm not sure if it really has four full CPUs. I think it might have two of those "dual core" thingys that have two processors but share the same I/O and cache or something. Here's a bit of the 'dmesg' output in case it's meaningful:

[    0.000000] Initializing CPU#0
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Calgary: detecting Calgary via BIOS EBDA area
[    0.000000] Calgary: Unable to locate Rio Grande table in EBDA - bailing!
[    0.000000] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    0.000000] Placing 64MB software IO TLB between ffff8800091de000 - ffff88000
d1de000
[    0.000000] software IO TLB at phys 0x91de000 - 0xd1de000
[    0.000000] Memory: 8185276k/8912896k available (5499k kernel code, 524948k a
bsent, 202672k reserved, 3081k data, 796k init)
...
[    0.020000] Initializing CPU#1
[    0.020000] CPU: Trace cache: 12K uops, L1 D cache: 16K
[    0.020000] CPU: L2 cache: 1024K
[    0.020000] CPU 1/0x6 -> Node 0
[    0.020000] CPU: Physical Processor ID: 3
[    0.020000] CPU: Processor Core ID: 0
[    0.020000] CPU1: Thermal monitoring enabled (TM1)
[    0.300088] CPU1: Intel(R) Xeon(TM) CPU 2.80GHz stepping 09
[    0.300099] checking TSC synchronization [CPU#0 -> CPU#1]: passed.
[    0.310146] Booting processor 2 APIC 0x1 ip 0x6000
[    0.020000] Initializing CPU#2
[    0.020000] CPU: Trace cache: 12K uops, L1 D cache: 16K
[    0.020000] CPU: L2 cache: 1024K
[    0.020000] CPU 2/0x1 -> Node 0
[    0.020000] CPU: Physical Processor ID: 0
[    0.020000] CPU: Processor Core ID: 0
[    0.020000] CPU2: Thermal monitoring enabled (TM1)
[    0.470108] CPU2: Intel(R) Xeon(TM) CPU 2.80GHz stepping 09
[    0.470120] checking TSC synchronization [CPU#0 -> CPU#2]: passed.
[    0.480175] Booting processor 3 APIC 0x7 ip 0x6000
[    0.020000] Initializing CPU#3
[    0.020000] CPU: Trace cache: 12K uops, L1 D cache: 16K
[    0.020000] CPU: L2 cache: 1024K
[    0.020000] CPU 3/0x7 -> Node 0
[    0.020000] CPU: Physical Processor ID: 3
[    0.020000] CPU: Processor Core ID: 0
[    0.020000] CPU3: Thermal monitoring enabled (TM1)
[    0.640119] CPU3: Intel(R) Xeon(TM) CPU 2.80GHz stepping 09
[    0.640128] checking TSC synchronization [CPU#0 -> CPU#3]: passed.
[    0.650032] Brought up 4 CPUs
[    0.650037] Total of 4 processors activated (22401.29 BogoMIPS).
-- 
Mike Orr <sluggoster at gmail.com>

[ Thread continues here (6 messages/16.81kB) ]



Share

Talkback: Discuss this article with The Answer Gang

Copyright © 2010, . Released under the Open Publication License unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 178 of Linux Gazette, September 2010

Tux