[gentoo-user] Re: Near freezes during large emerges

Alan McKinnon <alan.mckinnon@×××××.com> writes:

> Apparently, though unproven, at 03:39 on Monday 17 January 2011, William
> Kenworthy did opine thusly:
>
>> On Sun, 2011-01-16 at 17:26 -0800, Mark Knecht wrote:
>> > On Sun, Jan 16, 2011 at 5:13 PM, William Kenworthy <billk@×××××××××.au>
> wrote:
>> > > On Sun, 2011-01-16 at 14:41 -0800, Grant wrote:
>> ...
>>
>> > I think that's well worded. He has insufficient memory when emerging.
>> >
>> > If he's really running short of DRAM Then he might also do well to
>> > boot to a console and do his emerges there. No memory given over to
>> > other things like KDE or browsers, etc.
>> >
>> > I am a bit surprised though that a -j1 type emerge would be running
>> > out of memory on a 3GB machine. I just finished emerge updates on a
>> > desktop with 4GB and only used 2.5GB which includes KDE, FIrefox and a
>>
>> > number of other things:
>> I have a diskless 3GB ram atom system (mythtv frontend) and I have to
>> arrange swap over nbd for gcc and glibc emerges - others just get very
>> slow when getting to limits, or get flaky unless -j1 is used.  Havent
>> tried OO on it yet :)
>
> I'M flabbergasted. 3G is really a gigantic amount of memory and yet the
> machine still runs out of the stuff?
>
> Something is seriously wrong somewhere when code does this. I know memory is
> cheap and all, but still ... that's just excessive

Well, GCC has issues like this, with the file insn-attrtab, which, I
suppose, is generated and processed at least twice (due to the bootstrap
nature of the GCC build process). Although there's not a specific value,
even with 512 MiB of ram it's still an issue - but it doesn't go that
far (3GB), it's only more critical because GCC is a key part of the
toolchain.

This just to say, well, it happens :-)

-- 
Nuno J. Silva
gopher://sdf-eu.org/1/users/njsg