Em 21-08-2013 19:48, Ken Moffat escreveu:
On Sun, Aug 18, 2013 at 01:49:17PM -0300, Fernando de Oliveira wrote:
All 5 VMs finished. They run with 4 CPU's, are i686. Two, as I said
before, 1GB RAM, running in other host, 3 have 1.5GB, running on this
host that have many other things, including FF and TB, running as well.
In the other host, times were
SBU_TIME: 36.00411522
SBU_TIME: 35.76518218
In this host,
SBU_TIME: 49.10614525
SBU_TIME: 52.3750
SBU_TIME: 59.61038961
Perhaps, again, the fact that I have an AMD_64 running on a i686 host
running inside a 32bit vmplayer explains why this machine always gave me
trouble. It was built to replace this host. Would copy and change
whatever needed, for physical, instead of virtual hardware, as done
before, is more practical than what I did with LFS7.2, built directly on
a physical machine. But as I have written before, discovered that, for
many reasons, still need 32bit. Then, waited for LFS7.4, to build a new
complete one, 32bit. I only need 64bit for creating OJDK binary for the
book. Hope to start building tomorrow.
A couple of comments on SBUs - not sure if they relate to what you
wrote there, but I'd like to record what I do for package edits.
More or less. For the book, I run with j1. Above they ran with j4. But I
was amazed that the faster builds are in a much slower host. I think the
issue is that I am using a larger but slower HD, here. Some time ago,
speed of VM's here were almost double of the ones running in the older
host. I will have to revert that, some day (fast and slow HDs are still
in this host, just move the systems from one to the other.
This is prompted by my LFS-7.4 build on i686. The host was LFS-7.2
and a single-threaded initial SBU was 78.392 seconds (whoot! fast!).
But one of the first things I do on a new system is remove /tools,
recreate an empty /tools, and run the SBU commands as root. Usually
a gcc version increase means things run slower, and in this case
I've gone from 4.7.1 to 4.8.1. My SBU on this machine is now
150.849 seconds.
I will write down things that I think. I may be wrong, so, please tell
me, if I am.
SBU is good, necessary. SBU can never be trusted completely. Can never
be accurate. This host has SBU=133s (about measurement method, see
below), but 7.4-rc1, in a VM, in this same host, reported SBU=120s,
yesterday, so one must be wrong, or, inaccurate.
I have a script to generate the SBUs. However, each time it is executed
in the same machine, the value is different, most of times by small
amounts, but eventually, by large amounts (cannot remember if it could
be double the value or such). Perhaps the machines have their own
temper :-), they sometimes get slowing down, tired, have to leave X,
clean swap, restart video card module, restart VM services,logout, get
back... But, SBU is necessary, is a very good invention, cannot see how
it could be done differently, and gives an order of magnitude for the build.
About the method, I do aa thing similar to you, but run the script as
normal user and install using DESTDIR. I believe this should not differ
much from executing as root, in an empty tools, but if it is really
very different, please, tell me.
About the SBUs for mozilla's. I recall one day, VM with, perhaps, 512MB
of RAM, it was taking much much longer than previous versions. So
started watching libxul linking (did not understand it was linking, at
that time). It was taking what I recall much more than double the time
as previous ones (probably wrong memory is). Said in earlier post it had
1GB, but seems I started using them with 512MB. Point is, any changes,
SBU different.
When I'm putting a new version into BLFS I always try to measure it
on the current release. So my recent changes were measured on 7.3,
and whatever I do now will be measured on 7.4.
I always do that, but thanks to remind me. Always, before, or asap,
after, committing, try to build in the other machines. These will have j
with the number of CPUs, intead, just to be sure it builds and works,
not for SBU for the book.
I very much appreciate your help, elsewhere, and also here, thanks.
--
[]s,
Fernando
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page