Benchmark whether EROFS_FS_PCPU_KTHREAD & EROFS_FS_PCPU_KTHREAD_HIPRI increases cold boot performance

[ericcurtin]

If yes, try and get into Fedora, CentOS Stream 10, Automotive kernels.

[hsiangkao]

Hi @ericcurtin, I think EROFS_FS_PCPU_KTHREAD_HIPRI will reduce overall latencies due to scheduling, especially for Android runtime.
I'm not sure if it really help the specific use of automative system cold boot (I'm not sure the cold boot I/O pattern, maybe mainly impacted by sequential read), if yes, I guess you could improve this by using:

1. (readahead) adjust a larger read_ahead_kb temporarily;
2. (readahead) maybe use "ureadahead" or similar stuffs.
3. use a large pcluster size for specific files for better sequential read numbers, but it could have negative impacts on low memory scenarios though.

[ericcurtin]

@hsiangkao thanks for the tips! If you get some free time feel free to give this a run and provide further feedback 😊

[ericcurtin]

This solution is ahead on many of the benchmarks as you'll see in the graph in the README.md I just merged... But... Towards the end of the boot sequence by the time multi-user.target or graphical.target is reached for example... This erofs/initoverlayfs solution is slightly behind, because well, erofs eventually falls behind to the initramfs in memory although it starts ahead of initramfs-only.

[ericcurtin]

The goal is to propose this solution for all Fedora distros and hence RHEL, RHIVOS, etc. although the main driver is Automotive like you say where early boot services are required. It would be neat to have EROFS be a part of the boot sequence for at least the non-complex boots.

[hsiangkao]

@hsiangkao thanks for the tips! If you get some free time feel free to give this a run and provide further feedback 😊

I could seek some time to try this, yet I'm still mainly focuing on improving EROFS and erofs-utils theirselves to complete TODO items since it will benefit to all users. Time is limited and no so many active developers help so that is a bad news...