64 bit Dual-Core Moron
Sorry, I meant to go to the list.
---------- Forwarded message ----------
From: David Fox <firstname.lastname@example.org>
Date: Fri, Aug 1, 2008 at 12:34 PM
Subject: Re: 64 bit Dual-Core Moron
To: Account for Debian group mail <email@example.com>
On Fri, Aug 1, 2008 at 11:58 AM, Account for Debian group mail
> I looks like both CPUs are doing their thing on the kernel compile. Here
> is a quick look at the top info:
Are you doing a plain make or make -j 2 or something else?
The thing is, if you just do a 'make' then one core is mostly going to
be used by the compiler, and the other core might be used for all the
other processes. I just tried it myself. I was looking at top output
and there were plenty of times where one or the other of the cpus were
Since (I assume) you have a dual core cpu, then each of those cpus may
be able to hyperthread, so you might do a make -j 4.
Here's what I see (just a snapshot of top). I have other cpu-intensive
things running, like setiathome.
Tasks: 170 total, 8 running, 161 sleeping, 0 stopped, 1 zombie
Cpu0 : 89.4%us, 8.9%sy, 1.7%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 87.3%us, 11.3%sy, 0.0%ni, 0.3%id, 0.0%wa, 0.7%hi, 0.3%si, 0.0%st
Mem: 1932840k total, 1468592k used, 464248k free, 12336k buffers
Swap: 1951888k total, 40244k used, 1911644k free, 740692k cached
I see you have twice the RAM as I do. If you just do a make (or make
-j 4) your compiler processes are only using up a small portion of the
RAM. How do you go about making sure all that ram is being exercised?
That was my point. (Oh, and the system crashed my X session when I did
a make -j 128 on kernel 184.108.40.206 - chosen roughly at random.)
I noticed while I was compiling with plain 'make' that the memory was
hardly used, most of it was in free (over a gigabyte, with no X server
running) and it slowly drew memory from free and put it into buffers,
so that the cc1 process could be reloaded from there rather than from
disk, I guess. But it (cc1) never really ever used up more than 64
megs (and that's probably a generous upper limit for kernel compiles)
and presumably it was working on that same 64 meg area, although with
VM there's no way to tell.