On Mon, Feb 04, 2013 at 07:24:53PM -0600, Bruce Dubbs wrote: Sorry for the delay in replying - I left the 32-bit build running. It's now completed (and shown that my reduced ttf font build isn't rendering everything I intended), so I've now gone back to 64-bit to confirm how I set the kernel options.
> Ken Moffat wrote: > > On Mon, Feb 04, 2013 at 04:46:01PM -0600, Bruce Dubbs wrote: > >> > >> I don't understand why the number of processors would matter. > > > It's a desktop - when compiling some c++ packages the desktop > > becomes totally unresponsive for tens of seconds. This also > > happened on my other single-processor x86_64 which had adequate > > memory and faster cpu, faster disk. On my current multiprocessor > > desktops I haven't seen the problem. > > Be nice. Pun intended. LOL. My impression of nice is that you need to set it for a task - I suppose I could try using it on my buildscripts, but I never found it useful in the past. > > Actually, I thought that the scheduler would handle that properly by > itself, but you may have selected something in the kernel to change the > behavior. However, low memory does lead to swapping and I can see the > problems there. Building gcc does use a large amount of memory. > Testing gcc even more. > > Did you change the preemption model or other processor settings in the > kernel? > > -- Bruce Yes, "of course" and "everything" - if something is described as "experimental" and looks as if it _might_ be useful, I'll give it a try when building an -rc kernel. Usually, those settings get carried forward to newer kernels. I was building prerelease kernels before I ever came to LFS. On x86_64 I've got CONFIG_PREEMPT set. For IOSCHED I've accidentally picked up CFQ as the default (/me utters rude words about systemd), but I've been building NOOP and DEADLINE for years, and I'm reasonably sure that one of them was my default when I first noticed the problem - it's been a long time, probably about 2 years, since big C++ compilations made the desktop unresponsive. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
