64 bit Dual-Core Moron

["David Fox" <dfox94085@gmail.com>]

Sorry, I meant to go to the list.



---------- Forwarded message ----------
From: David Fox <dfox94085@gmail.com>
Date: Fri, Aug 1, 2008 at 12:34 PM
Subject: Re: 64 bit Dual-Core Moron
To: Account for Debian group mail <debian@pcez.com>


On Fri, Aug 1, 2008 at 11:58 AM, Account for Debian group mail
<debian@pcez.com> wrote:
> 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
essentially idle.

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