nice(1) level during build

Sebastian Faulborn sfaulborn at web.de
Mon Jul 3 19:07:48 PDT 2006


>On July 3, 2006 09:55 am, Sebastian Faulborn wrote:
>> If your system has a load of 8, uses all main memory and swap (!) just by
>> running a single application (make bootstrap), then there must be something
>> seriously wrong!
>
>I have not attempted to reproduce it, but with nice -n 19 the 'make bootstrap' 
>didn't cause a repeat of the problem. It could have been a combination of 
>things which were running at the same time. uClibc and gcc-4.1 don't get 
>along very well, so I pointed the finger at that.
>
>I think the majority of users build lfs/hlfs on a desktop system while running 
>a gui/xorg. In these situations running 'make', and './configure', with 
>'nice' is always a good idea, to keep the gui responsive.
>
>> So I rather prefered to fix the problem rather than setting nice levels.
>
>I agree, but using a nice level controls unexpected problems. If we start 
>using a lot of gcc options, like -DFORTIFY_SOURCE=2 -fstack-protector-all 
>-Wformat=2 -Wsecurity -Wshadow -Werror -lmudflap, with maybe additional 
>options like -fwhole-program -combine -fprofile-use, this starts using 
>considerably more resources to compile and has a higher risk of getting out 
>of control (while unstable).
>
>robert

1) If you need a more responsive gui, try compiling your kernel with
Processor type and features -> Preemption model (Desktop)
                            -> Timer frequency (250Hz)

With these settings, your system should be as responsive while
compiling HLFS as if the system was idle. I usually surf the internet
with firefox while compiling HLFS with practically no delay.

2) I still think there is something awfully wrong here. If an application
starts using up all main memory and swap, it has basically a huge 
memory leak. Also think about it: "make" starts a new gcc process for every
source file which needs to be compiled. Source files are usually a lot smaller
than 100kB - so its very unlikely that gcc consumes all memory at all.
On my system gcc consumes at most 10MB. My system has 512MB main memory,
80MB is free, swap is not used at all (at most 20kB or so), load is at most
1.5. 

Basically what you are saying is that in the near future the requirements
for compiling HLFS will be a system with at least 1GB main memory and
several GBs of swap - and pray that gcc is not using up all of it before
it has finished! The current HLFS builds with 128MB main memory and 
10MB swap with no problems at all...

So I believe there is a bug somewhere in the memory management. Probably
in uClibc-0.9.28. Maybe gcc's memory is not released as quickly as it should
after a process has finished?

Can you find out which process is actually consuming all memory? Does the
problem exist with glibc? I have only tried the current glibc branch.

If we cannot find the cause, we basically may end up with an highly unstable
system!

Sebastian Faulborn
Homepage: http://www.secure-slinux.org








More information about the hlfs-dev mailing list