[ale] Performance

[Jeff Hubbs]

Danny -

That's interesting and it kind of mirrors my recent experiences with
putting Gentoo on paperweights (P/60, P/100, P/ 133).  Working from
Stage 1 Gentoo installs, the kernel compile is just the tip of the
iceberg, but when the machine is so slow, you can run top, watch the
drive light, and follow what's going on.  

It seemed as though, with a make -j of 2, disk I/O was only occasional. 
It did probably amount to a significant percentage of time taken
overall, but the CPU was what was getting pounded and pounded hard, as
was the RAM at times (with a gcc -O of 3).  

This is Gentoo-specific, but I did try to put /usr/portage on its own
~450MB drive (albeit a nice one - 5400RPM and five physical heads) and
formatted it as Reiser since the files in the portage tree tended to be
1-5K.  I can't prove that that helped emerges any but I felt like I was
doing the best I could do with the hardware on hand.





On Fri, 2003-11-07 at 18:38, Danny Cox wrote:
> Jeff,
> 
> On Fri, 2003-11-07 at 13:44, Jeff Hubbs wrote:
> > OK, I read you - but regarding the "disk IO on all the small files," is
> > this mostly a read operation or a write operation?  Reason I ask, how
> > would it be to leave at least the reading coming from disks on the
> > individual Mosix nodes, from kernel trees set up via rsync ahead of
> > time? 
> > 
> > When you did this, how did you establish the shared cluster file space?
> > NFS?  Mosix File System (something I need to look into again - it's been
> > a while)?
> 
> 	Just for kicks, I made a RAM disk large enough to hold the kernel
> source plus objects.  This was on a dual Athlon 1.2 GHz with 1GB ram. 
> Made no difference, or perhaps I may recall a couple of seconds here or
> there.  Certainly down in the grass.
> 
> 	Fully 98% of the time compiling is full CPU.  The I/O is negligable in
> comparison.  gcc -O2 comsumes lots of memory, but is also CPU
> intensive.  The best way to speed up compiles is a faster CPU, or, as
> others have suggested, many fast CPUs, either via SMP, distcc, or both.
> 
> 	Now, if you do lots of "make clean; make" type work, check out ccache
> (ccache.samba.org).  It's the classic time/space tradeoff.  Spiffy!
-- 
Jeff Hubbs <hbbs at comcast.net>