On Monday 18 April 2011 17:49:16 Dave Hajoglou wrote: > On Thu, Apr 14, 2011 at 10:00 AM, Bruce Dubbs <[email protected]> wrote: > > There is definitely something wrong. On a production LFS system running > > in a virtual envronment, I get: > > > > real 0m18.514s > > user 0m8.984s > > sys 0m2.697s > > I'm still having the same problems after recompiling the kernel a few > times with different options. Ken, I don't know how to check against > the 32 v 64 bit. uname reports:
... > If I run this in a loop on the LFS > box top shows the following while bash only consumes around 7 to 9% of > the cpu and a scant of memory. > > Cpu(s): 0.0%us, 25.7%sy, 0.2%ni, 74.0%id, 0.0%wa, 0.0%hi, 0.2%si, > 0.0%st (IIRC, this is running in a VM.) Most of the time is being spent in the system. If I had to guess, I'd say the host is emulating something; the virtual kernel is doing or accessing something that cannot be done natively, or is accessing something on the host which is being subjected to strong contention. *Something* is causing the kernel to spinlock or otherwise tarry (poke along). > > > I'm not sure why you want multiple CPUs in a virtual environment when > > you can clone a new one for each task. IMO, no computer today should ever have less than 2 full cores, be it virtual or metal. If the task involves concurrent operation of more than one thread or process, then having multiple vCPUs makes sense. Even a simple '-j 1' compile can involve concurrency: the kernel can be reading/writing the file system while the compiler is working on a large, complex source file. Packing or unpacking a compressed tarball involves gzip/bzip/xz, tar and disk I/O. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
