This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: PATCH to avoid linking multiple front ends at once with parallel make
- From: Dave Korn <dave dot korn dot cygwin at gmail dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Alexandre Oliva <aoliva at redhat dot com>, gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 05 May 2013 14:57:18 +0100
- Subject: Re: RFC: PATCH to avoid linking multiple front ends at once with parallel make
- References: <518077C0 dot 4050703 at redhat dot com>
On 01/05/2013 03:02, Jason Merrill wrote:
> Since GNU Make doesn't support anything like the .MUTEX directive
> (http://savannah.gnu.org/bugs/?func=detailitem&item_id=17873), and
> accidentally doing "make -j8 -l4" makes my laptop useless for several
> minutes while it tries to link all the front ends at once, I decided to
> kludge a workaround.
>
> This hack uses mkdir as a locking mechanism, as it fails if the
> directory already exists. Each front-end rule first tries to get the
> lock, and spins if the lock isn't available. Currently I'm enabling the
> locking by default on build hosts with less than 8GB of memory.
>
> Releasing the lock is not reliable; if the user interrupts the link with
> ^C, the lock will remain. So I adjusted 'make all' to remove the lock
> early on, though that only works for the typical case, and users that do
> something like 'make cc1plus' could still run into trouble.
>
> Thoughts? Is this too horrible a hack, or does it seem like something
> we might want?
>
> Maybe I should fix Make instead.
This sounds like a bad idea to me, and not just because the locking
mechanism is dodgy. Is the problem more widespread than just your laptop?
Does it affect other host OSs? Linking multiple frontends at once doesn't
lock up my desktop PC, so I'd rather not have it disabled.
Why don't you just nice your build shell? Shouldn't that make the rest of
your system responsive?
cheers,
DaveK