Linux Kernel Performance Bottlenecks Spotted By Mold Developer

[phoronix]

Phoronix: Linux Kernel Performance Bottlenecks Spotted By Mold Developer

Open-source developer Rui Ueyama who is the lead developer of the Mold high performance linker and previously on the LLVM lld linker has written a detailed mailing list post that highlights some observed performance bottlenecks within the Linux kernel...

https://www.phoronix.com/news/Linux-Kernel-Bottlenecks-Mold

[Anux]

1 sec file creation? Do we know which file system he was using?

[davidbepo]

lmao, dude is so good at making fast linkers, the kernel is now holding him down
this guy is super talented, i hope he gets better support

[Wielkie G]

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.

[schmidtbag]

I also wonder if the file system would have an impact. But even if it didn't, makes sense to me that creating a new file would take longer. Creating a new file still requires you to write the file information, even if the file is just 0B. Even just recording atime has a noteworthy impact on performance, so surely recording creation time, modification time, the file name itself, updating inode tables, updating indexes, recording file attributes, etc is going to make a dent on performance. A lot of that stuff doesn't have to be done after a file already exists.

[waxhead]

I also wonder if the file system would have an impact. But even if it didn't, makes sense to me that creating a new file would take longer. Creating a new file still requires you to write the file information, even if the file is just 0B. Even just recording atime has a noteworthy impact on performance, so surely recording creation time, modification time, the file name itself, updating inode tables, updating indexes, recording file attributes, etc is going to make a dent on performance. A lot of that stuff doesn't have to be done after a file already exists.

I was thinking the same, and it is quite logical that creating a new file is slower than appending to an existing file that already have all the structures set up... At the same time I wonder if it possibly could be an idea for a filesystem to "pre-allocate" some empty files so that "creating" a new file really was no more than simply marking the file active and updating the minimum of data (atime, etc) necessary.

[ddriver]

lmao, dude is so good at making fast linkers, the kernel is now holding him down
this guy is super talented, i hope he gets better support

He should write his own os kernel rather than using inferior legacy software.

[Anux]

Even just recording atime has a noteworthy impact on performance, so surely recording creation time, modification time, the file name itself, updating inode tables, updating indexes, recording file attributes, etc is going to make a dent on performance. A lot of that stuff doesn't have to be done after a file already exists.

On an SSD this should take a few ms not a whole second.

[mihau]

he's impressive but "Mold Developer" will never not be funny to me

[stormcrow]

On an SSD this should take a few ms not a whole second.

Depends on the SSD, FS, bus attachment, and how full it is. Broad generalizations like this aren't helpful in diagnosing problems of this sort. I found the details in the post lacking, as I'm sure some of the kernel devs will.