| Newsgroups |
gmane.linux.lfs.beyond.devel |
| Message-ID |
<[email protected]> |
Am 20.08.26 um 18:07 schrieb Bruce Dubbs ([email protected] via
blfs-dev Mailing List):
> On 8/20/26 4:55 AM, Rainer Fiebig ([email protected] via blfs-dev Mailing
> List) wrote:
>> Am 20.08.26 um 05:37 schrieb Bruce Dubbs ([email protected] via
>> blfs-dev Mailing List):
>
>>>> We already say in "notes on building software":
>>>> ---
>>>> Some compilations with g++ may consume up to 2.5 GB
>>>> of memory, so to be safe, you should restrict the number of jobs
>>>> to (Total Memory in GB)/2.5, at least for big packages such as LLVM,
>>>> WebKitGtk, QtWebEngine, or libreoffice.
>>>> ---
>>>> I think now 2.5 should be replaced with 3. Also, I've never seen a
>>>> problem in libreoffice or llvm...
>>>
>>> Yes, I think you are right. We do have a paragraph in an 'Important'
>>> note in Webkit. My problem is that I haven't run into it before on a
>>> system with 64G of RAM.
>>
>> You were just lucky. I'm consternated that you operate a 28-thread-box
>> with a measly 64 GB of RAM. And then wonder that you run out of memory
>> when building the latest version of one of the finest bloatware around.
>>
>> The solution is of course _not_ that you use fewer threads, as
>> thougthlessly recommended by others. I mean, what sense makes a
>> 28-threads-CPU if you can use only half of it?
>>
>> The solution is also _not_ to try to fight "The Bloat". Because that
>> would be futile, "The Bloat" is invincible.
>>
>> Therefore, the only rational (and obvious) thing to do here is to add
>> more memory, 64 GB may do for now. Adding more memory would also be in
>> line with what _you_ recommended in similar cases, if IIRC. ;)
>>
>> Only if you find that a bit unattractive or even prohibitive because of
>> RAMaggedon-prices should you ponder to use fewer threads. But really
>> only as a last resort.
>
> At one time I ran into the memory problem with Webkit on a 24 core
> system with 32G. I did upgrade to 64G and then checked the max RAM
> usage. It was 44G. Now Webkit exceeds 64G with only 4 more cores.
> That was unexpected. For other packages I do not recall having a
> problem when I had 32G.
>
> Adding RAM amounts to a cost/benefit calculation. A problem with one
> bloated package that can be easily fixed with a trivial setting makes
> more sense to me than adding RAM. OTHH if I wanted to continuously run
> one or more VMs on the same system, it would make sense.
Bruce, don't take my post _too_ seriously. I was just making a bit fun
of the situation. But there is a serious side, too: when one runs into
an OOM-problem with a generous 64 GB of RAM something is wrong. That
should not be, not even when using 28 threads.
When memory- and storage-prices began to rise to the now absurd and
painful levels, I thought that at least _this_ might give developers
reason to pause, rethink and finally begin to show a little restraint.
Perhaps even begin to subtract instead of constantly adding. But it
doesn't happen, obviously. They plough on like ever before if not
worse. Not good, at least in my opinion.
Rainer
--
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page