Linux Kernel Performance Bottlenecks Spotted By Mold Developer

[stiiixy]

And, as far as I know, those things are SATA3, not SATA1, just like the cheap WD Blue SSDs in my mother's old laptop, my hand-me-down laptop, and the hand-me-down 2012 HP prebuilt that I turned into a "game console but not a console". Hell, the 2011 Athlon I used to be using does SATA3 and has a WD Blue I'll probably repurpose as I slowly part it out.

There's no reason aside from "test platform for preventing minimum requirements creep" for a developer to be using something that drives the link at 1.5Gbits instead of 6Gbits in this day and age.

Probably out of context considering SSD is the theme, but SDCard.

[AdrianBc]

The first two points are nothing new as he has described them already since the very first version of mold (if I recall correctly). It is just the first time this has been brought forth to the kernel developers.

I cannot speak about the last point though. It might be a more recently found issue.

For the last point, it seems that there are several solutions that he has not tried.

For example, each linker process can attach a shared memory segment with "shmat".

The number of processes attached to the shared memory segment can be obtained with "shmctl".
Also with "shmctl", the segment can be marked to be deleted when the last process detaches from it.

When a process exits, it is automatically detached from any such shared memory segment.

This provides exactly the behavior requested by him, which enables the detection of how many linker processes are active, so Linux does not need any change from this point of view. These are ancient system calls belonging to UNIX System V IPC, so they are not widely known today.

[ssokolow]

Probably out of context considering SSD is the theme, but SDCard.

True, but that's sort of like pointing to SATA as a reason to keep a first-generation NVMe drive around for testing.

If you want to choke things down, there are plenty of ways using modern technology, rather than old stuff that's harder to replace if it dies. (Hell, I haven't tried it, but you could probably simulate ancient storage technology performance by hitting NewEgg's "Under 5400RPM" filter and pairing what you find with a $3 SATA-to-IDE and a $3 IDE-to-SATA adapter off AliExpress. (Assuming you can't just simulate it in software using something like hdparm.)

[Anux]

Most of what I said is not limited to disk bandwidth. There's quite a lot of overhead to collect the necessary information and to communicate over the various busses.

You mean on the hardware side? I doubt it, any recent hardware should have no problem to do such operations in a few ms. The only thing could be file system or driver/kernel related bugs.
You could also conclude hat from the description, that it is faster if the file exists. Hardware doesn't care about that, it only writes data.