Re: WebKitGTK-2.52.5

Hi all,

On Wed, 19 Aug 2026, Bruce Dubbs wrote:

> On 8/19/26 10:10 PM, Pierre Labastie ([email protected] via blfs-dev 
> Mailing List) wrote:
>> On Wed, 2026-08-19 at 20:56 -0500, Bruce Dubbs wrote:
>>> On 8/19/26 6:51 PM, Bruce Dubbs wrote:
>>>> On 8/19/26 5:46 PM, Zeckma ([email protected] via blfs-dev
>>>> Mailing List) wrote:
>>>>> On 8/19/26 15:58, Bruce Dubbs ([email protected] via blfs-dev
>>>>> Mailing List) wrote:
>>>>>   > I had a bit of a problem with building WebKitGTK-2.52.5 on a
>>>>> 13.1
>>>>>   > system. I'm using a system with 28 cores.  When I tried to
>>>>> build
>>>>>   > WebKitGTK-2.52.5 using all 28 cores, it failed to build.  The
>>>>>   > message was something about a file that was not complete.  I
>>>>>   > tried twice and it failed at the same point.  I then tried at
>>>>> -j8
>>>>>   > and the build was successful.
>>>>> 
>>>>>
[...]
>> I'm almost sure it is an OOM problem. On a 16GB virtual machine, I need
>> to pass -j3. -j4 and higher fails. Those "UnifiedSource" files may need
>> more than 3GB for compilation. So at -j4, I may need ore than 12GB,
>> which together with memory used by the system makes it more than 16GB.
>> 
>> 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.

Now that the topic comes up, I think I have quite something to share with 
you...:

I just built WebKitGTK-2.52.6 succesfully on a system with 6 cores / 12 
threads and only 16GB of RAM - with -j12, while using the system (X with 
icewm and audacious running) simultaneously, in "just" 77min wallclock 
time. As you noticed, this is not a trivial thing to do. Out of the box 
this would for sure either break or be *much* slower due to Memory 
Pressure.

For quite some time I had limited NINJAJOBS to 6 or 7 for webkitgtk (in 
contrast to other packages) to keep the system usable, any higher would 
run into memory problems severe enough to make playing mp3s stutter. In 
February, it bugged me that webkitgtk builds got bigger and bigger and 
even with 6 or 7 there was occasional stutter. Nevertheless 7 was faster 
overall than 6. Buying memory was/is not very attractive, so I tried 
pretty much everything that came into my or Geminis mind to keep 
parallelism as high as possible or build times as low as possible while 
keeping the system usable.

From using cgroups or zram, over tuning kernel parameters, to making 
NINJAJOBS dynamic during the build etc. I learned quite a lot, quite a 
lot of ideas turned out to be either irrelevant or less effective than 
expected or even contra productive. Most system mechanism are already 
rather good and it is not trivial to make it better.

First of all you are usually missing a good measure whether you (start to) 
have a resource problem or whether your resource usage is effective. High 
load for example is not a good indicator. In the past, I saw a load of 
12, all cores have something to do, parallelism is good. Well, not quite 
- they have *something* to do does not mean it is productive. While 
actual cores are really getting work done, their partner threads are more 
like waiting for shared resources. In SMT, in a good scenario, you can 
expect a benefit of ~30% from such partner thread, so basically if you 
have no memory issue at all, a 6 core / 12 thread machine running with 
-j12 on full load will get the work done in about the same time as 7.8 
real cores. This is about the maximum you can get by throwing money in 
form of memory onto the problem.

The webkitgtk build is quite heterogenous, there are times where -j12 is 
really benefical. Load may even go up to 15 without negative effect on a 
12 thread machine. But there are also times building unified sources that 
eat up memory. A lot. The big chunks way more than 2.5GB per child. You 
are having a problem when the kernel announces Memory Pressure. But then 
it is already too late, the big unified source compile jobs are already 
started, and they will get bigger until they finish, just stopping ninja 
from spawning more children is already too late. There is an earlier 
indicator though - Available Memory. If that gets below ~2.5GB, you are 
quite likely to run into memory trouble soon. You somehow need to 
prioritize the big child compile jobs to complete and free their memory 
soon. The best way I found to achieve that is to pause all but the biggest 
6 child processes so effectively each fat one has a core for its own.

I achieve that by letting this absolutely-bash-only surveillance script 
https://uwe-dueffert.de/code/stopcontkids.sh run in background to monitor 
and control the build process. Back in February, this brought down my 
overall webkitgtk build time from ~77min to ~70min while keeping the 
system usable. That's about the best it will get without throwing 
memory/money onto the problem, but even that would not be expected to get 
it *much* faster.

The approach turned out to be working with all newer webkitgtk versions 
since then without modification. Parameters may not be perfect for 
WebKitGTK-2.52.6 anymore, but still usable. The script logs what happens, 
which can be visualized: 
https://uwe-dueffert.de/code/stopcont_webkitgtk2526.png
Blue is the indicator Available Memory, if that gets too low 
stopcontkids.sh steps in and stops the smaller ninja child processes (Red 
line goes down from 6000 ("6 additional threads are allowed to run") down 
to 0 ("only 6 fattest children get their own core"). Yellow is actual 
Memory Pressure. Would be better to avoid that completely, but this way it 
is limmited to a handable amount and each time resolved rather fast by 
prioritizing fat children. When those finish my script allows small 
children to continue.

The webkitgtk developers seem to be well aware of the resource hunger of 
their build process. "Newer" versions have dramatically reduced it since 
February: webkitgtk-2.53.4 source package is only 45MB instead of 63MB of 
webkitgtk-2.52.6 and builds in only 29min instead of 77min on my machine.

I'm not proposing that for the books in any way, but I hope it sheds quite 
some light onto the issue for those interested in it.

Cheers
Uwe

-- 
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page