Ken Moffat wrote: > On Sun, Feb 03, 2013 at 09:28:39PM -0500, Michael Shell wrote: >> On Mon, 4 Feb 2013 01:30:21 +0000 >> Ken Moffat <zarniwh...@ntlworld.com> wrote: >> >> >>> I'm now in the process of downgrading my oldest x86_64 to x86_32 [ >>> i.e. i686 ] - recent g++ is unusable on a desktop x86_64 with only >>> 2 GB of memeory and a uniprocessor (i.e. the desktop becomes >>> unresponsive when compiling). >> >> >> I'm sure you probably already know about this, but just for the record, >> did you try altering the I/O scheduler to something else such as >> deadline: >> >> http://stackoverflow.com/questions/1009577/selecting-a-linux-i-o-scheduler >> http://www.linuxplanet.com/linuxplanet/tutorials/6880/1 >> > Yes, used that for years. Thanks. > >> If it really is low RAM, what causes 2GB to be eaten up so quickly >> in an x86_64 environment (which does not happen under the x86_32)? >> > Don't know, and I haven't successfully booted the new system yet [ > forgot to build devtmpfs in the kernel ], but the build (from xorg) > was also swapping on x86_32 so it might not be any better. On my > new (SMP) boxes, LFS-7.2 is fine.
I'm not sure about why you would have a problem with the memory. I did do a LFS build recently on a cloud server with only 512M of ram. gcc did run it oom, but adding a swap file cleared that up -- it just took longer. I don't understand why the number of processors would matter. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
