Specs:
dual "MP unlocked" Athlon XP 1900+ (4th bridge of L5 is closed)
MSI K7D Master-L (MS-6501 v1.0), AMD 760 MPX
2 x 512 MB DDR-SDRAM 266, CL2, unregistered, no ECC
Linux SMP 2.4.19-rc1-jam2 + Page Coloring
PCI devices found:
Bus 0, device 0, function 0:
Host bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] System
Controller (rev 17).
Master Capable. Latency=32.
Prefetchable 32 bit memory at 0xe8000000 [0xebffffff].
Prefetchable 32 bit memory at 0xee100000 [0xee100fff].
I/O at 0xc400 [0xc403].
Bus 0, device 1, function 0:
PCI bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] AGP Bridge
(rev 0).
Master Capable. Latency=32. Min Gnt=14.
Bus 0, device 7, function 0:
ISA bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ISA (rev 5).
Bus 0, device 7, function 1:
IDE interface: Advanced Micro Devices [AMD] AMD-768 [Opus] IDE (rev 4).
Master Capable. Latency=32.
I/O at 0xc000 [0xc00f].
Bus 0, device 7, function 3:
Bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ACPI (rev 3).
Master Capable. Latency=32.
Bus 0, device 16, function 0:
PCI bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] PCI (rev 5).
Master Capable. Latency=32. Min Gnt=6.
Bus 1, device 5, function 0:
VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 4 / Voodoo 5 (rev
1).
IRQ 17.
Non-prefetchable 32 bit memory at 0xe0000000 [0xe3ffffff].
Prefetchable 32 bit memory at 0xd8000000 [0xdfffffff].
I/O at 0xb000 [0xb0ff].
Bus 2, device 0, function 0:
USB Controller: Advanced Micro Devices [AMD] AMD-768 [Opus] USB (rev 7).
IRQ 19.
Master Capable. Latency=32. Max Lat=80.
Non-prefetchable 32 bit memory at 0xed122000 [0xed122fff].
Bus 2, device 4, function 0:
Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 8).
IRQ 16.
Master Capable. Latency=32. Min Gnt=2.Max Lat=20.
I/O at 0x9000 [0x901f].
Bus 2, device 4, function 1:
Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 8).
Master Capable. Latency=32.
I/O at 0x9400 [0x9407].
Bus 2, device 5, function 0:
Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 4).
IRQ 17.
Master Capable. Latency=32. Min Gnt=8.Max Lat=56.
Prefetchable 32 bit memory at 0xee000000 [0xee000fff].
I/O at 0x9800 [0x981f].
Non-prefetchable 32 bit memory at 0xed000000 [0xed0fffff].
Bus 2, device 6, function 0:
SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U (rev 1).
IRQ 18.
Master Capable. Latency=32. Min Gnt=8.Max Lat=8.
I/O at 0x9c00 [0x9cff].
Non-prefetchable 32 bit memory at 0xed120000 [0xed120fff].
Bus 2, device 9, function 0:
Ethernet controller: Intel Corp. 82559ER (rev 9).
IRQ 17.
Master Capable. Latency=32. Min Gnt=8.Max Lat=56.
Non-prefetchable 32 bit memory at 0xed121000 [0xed121fff].
I/O at 0xa000 [0xa03f].
Non-prefetchable 32 bit memory at 0xed100000 [0xed11ffff].
/home/nuetzel> sensors
eeprom-i2c-0-50
Adapter: SMBus AMD768 adapter at 06e0
Algorithm: Non-I2C SMBus adapter
Memory type: SDRAM DIMM SPD
SDRAM Size (MB): invalid
12 1 2 144
eeprom-i2c-0-51
Adapter: SMBus AMD768 adapter at 06e0
Algorithm: Non-I2C SMBus adapter
w83627hf-isa-0290
Adapter: ISA adapter
Algorithm: ISA algorithm
VCore 1: +1.71 V (min = +4.08 V, max = +4.08 V)
VCore 2: +2.48 V (min = +4.08 V, max = +4.08 V)
+3.3V: +3.36 V (min = +3.13 V, max = +3.45 V)
+5V: +4.94 V (min = +4.72 V, max = +5.24 V)
+12V: +12.08 V (min = +10.79 V, max = +13.19 V)
-12V: -12.70 V (min = -13.21 V, max = -10.90 V)
-5V: -5.10 V (min = -5.26 V, max = -4.76 V)
V5SB: +5.38 V (min = +4.72 V, max = +5.24 V)
VBat: +3.42 V (min = +2.40 V, max = +3.60 V)
U160: 0 RPM (min = 3000 RPM, div = 2)
CPU 0: 4500 RPM (min = 3000 RPM, div = 2)
CPU 1: 4272 RPM (min = 3000 RPM, div = 2)
System: +33.0?C (limit = +60?C, hysteresis = +127?C) sensor = thermistor
CPU 1: +41.5?C (limit = +60?C, hysteresis = +50?C) sensor = 3904
transistor
CPU 0: +43.0?C (limit = +60?C, hysteresis = +50?C) sensor = 3904
transistor
vid: +18.50 V
alarms: Chassis intrusion detection
beep_enable:
Sound alarm disabled
During compilation of the glibc.
Do you need more info?
Alan, were should I put the "-j2/-j3" make flag for the kernel compilation?
/usr/src/linux/Documentation/smp.txt is way outdated ;-(
Is there a place (maybe in /usr/lib/rpmrc; SuSE/RedHat) to get both CPUs
running during RPM packages compilation?
Thanks,
Dieter
--
Dieter N?tzel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
@home: [email protected]
On Thursday 18 July 2002 08:31 pm, Dieter N?tzel wrote:
> Alan, were should I put the "-j2/-j3" make flag for the kernel
> compilation? /usr/src/linux/Documentation/smp.txt is way
> outdated ;-(
>
> Is there a place (maybe in /usr/lib/rpmrc; SuSE/RedHat) to get
> both CPUs running during RPM packages compilation?
Alan may have a different answer for you, but in my experience,
you can just specify the -j<whatever> flag when you run make
(and also set the MAKE variable to "make -j<whatever>". The
speed benefit really kicks in when making bzImage or modules.
In general, I find it best to set the number of jobs to the
number of CPUs _plus 1_--i.e. for single CPU, use make -j2, and
for dual CPUs, use make -j3. Going for that "plus 1" makes most
builds just a smidgen faster. For me, on my dual PPro box, the
process would be something like:
make menuconfig
make -j3 MAKE="make -j3" dep clean bzImage modules
Doing just a bare "make -j" (using just "-j" where you'd normally
use "-j<whatever>") is never good, even if you actually do have
tons and tons of mem+swap. Besides sucking up memory like
there's no tomorrow, it hammers the system with context switches
and forces the build to spend way too much of its time stuck in
the process scheduler. This makes a nice brutal stress-test for
a system, but it slows your build to a crawl.
AFAIK, the only way to get RPM packages to use "make
-j<whatever>" is to edit their spec files manually, have the
%build scriptlet look in /proc/cpuinfo to discover the number of
CPUs, and then have the scriptlet explicitly call make with
appropriate -j parameters. You might want to do this both in
the %build and %install scriptlets, since environment variable
settings in the %build scriptlet don't necessarily carry over
into %install.
Beware, also, that many build scripts will not work properly with
"make -j<whatever>". A parallel build as a whole may work, or
it may not. Some source packages may fail loudly and die. A
few may appear to complete successfully, yet silently fail to
install some file or another. It's fairly common for source
trees not to be 100% "parallel-build safe", and the kernel is no
exception.
You could possibly complain to developers about this, but most
developers have higher priorities than catering to people with
multiple CPUs. ;) So using "make -j<whatever>" should always be
considered "experimental."
--
Kelledin
"If a server crashes in a server farm and no one pings it, does
it still cost four figures to fix?"
On Thu, Jul 18, 2002 at 09:14:30PM -0500, Kelledin wrote:
> On Thursday 18 July 2002 08:31 pm, Dieter N?tzel wrote:
> > Alan, were should I put the "-j2/-j3" make flag for the kernel
> > compilation? /usr/src/linux/Documentation/smp.txt is way
> > outdated ;-(
...
> In general, I find it best to set the number of jobs to the
> number of CPUs _plus 1_--i.e. for single CPU, use make -j2, and
> for dual CPUs, use make -j3. Going for that "plus 1" makes most
> builds just a smidgen faster. For me, on my dual PPro box, the
> process would be something like:
>
> make menuconfig
> make -j3 MAKE="make -j3" dep clean bzImage modules
I usually have better luck if I use only one target per 'make':
make menuconfig
make -j3 dep
make clean
make -j3 bzlilo
make -j3 modules
make -j3 modules_install
Especially, 'modules' and 'modules_install' must be done separately.
--
William Park, Open Geometry Consulting, <[email protected]>
8-CPU Cluster, Hosting, NAS, Linux, LaTeX, python, vim, mutt, tin
On Thu, 18 Jul 2002, Kelledin wrote:
> Alan may have a different answer for you, but in my experience,
> you can just specify the -j<whatever> flag when you run make
> (and also set the MAKE variable to "make -j<whatever>". The
> speed benefit really kicks in when making bzImage or modules.
>
> In general, I find it best to set the number of jobs to the
> number of CPUs _plus 1_--i.e. for single CPU, use make -j2, and
> for dual CPUs, use make -j3. Going for that "plus 1" makes most
> builds just a smidgen faster. For me, on my dual PPro box, the
> process would be something like:
>
> make menuconfig
> make -j3 MAKE="make -j3" dep clean bzImage modules
These do different things...
If you put -j3 on the command line as an option to the primary make, it
can (will) run that many processes and do things out of order. If you use
MAKE='make -j3' it only takes effect after a new make process is started.
So you can put all the things on one command line and they will be run to
completion sequentially. I find this helpful to avoid mixing bzImage and
modules, one may get an error and the other will keep on going, scrolling
the error off the screen.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.