search

the-modem-distro / meta-qcom

Forked repository from the Yocto project
MIT License
30 stars 8 forks source link

remount: Avoid multiple remounts #5

Closed PsychoGame closed 3 years ago

PsychoGame commented 3 years ago

Each remount adds up to total boot time. Try to encapsulate all cases into 1 remount action.

Biktorgj commented 3 years ago

This isn't acually triggered unless the user breaks something in the filesystem, as all those folders are created always when building the image, so this is just a fallback in case someone breaks something without knowing it and makes the rootfs unbootable.

The one place where we spend more time than we should is in the ubi image mounting, that seems to be expensive as hell for the kernel (1.5 seconds of attach+mount). I could move to another filesystem but then I the bootloader would stop being compatible with the stock firmware, so a little tricky

PsychoGame commented 3 years ago

I noticed it indeed when skimming over the build files some more. Nonetheless the script looks cleaner this way, so it could prove as a cosmetic clean-up. But I leave that up to you.

Edit 1: @Biktorgj I may have found a way to make the bootloader loading another fs, but in the meantime keeping the ubifs booting intact for compatibility with stock firmware. What FS did you have in mind to use, plain ext4?

In the init.c of the mdm9640 target, there is a piece of code about "get_target_boot_params". While this piece of code is differentiating between booting from UBI (NAND) device or Ext4 (EMMC) device, wouldn't it be possible to make a conditional check on the filesystem in use? Let me know what you think about this?

Biktorgj commented 3 years ago

I noticed it indeed when skimming over the build files some more. Nonetheless the script looks cleaner this way, so it could prove as a cosmetic clean-up. But I leave that up to you.

Edit 1: @Biktorgj I may have found a way to make the bootloader loading another fs, but in the meantime keeping the ubifs booting intact for compatibility with stock firmware. What FS did you have in mind to use, plain ext4?

In the init.c of the mdm9640 target, there is a piece of code about "get_target_boot_params". While this piece of code is differentiating between booting from UBI (NAND) device or Ext4 (EMMC) device, wouldn't it be possible to make a conditional check on the filesystem in use? Let me know what you think about this?

Will take a look! Honestly I don't know how much time will it need to mount an ext4 fs compared to ubi, but it seems to take a lot to "attach" the ubifs so if we can take a bit from it the better :)

Edit: I will merge this, but don't want to add more changes to the current build until I publish a non-prerelease build, so will keep it open for a day or two before merging

PsychoGame commented 3 years ago

This morning I found some interesting things about UBIFS, when investigating it's capabilities, advantages and disadvantages. In this research I'm convinced that UBIFS is the proper filesystem for our case, and there are some improvements possible to the current UBIFS filesystem. The slow ubiattach was a known problem pre kernel 3.7, that's why they came up with UBI Fastmap. This UBI Fastmap technology isn't build into our kernel currently. It needs to be enabled by setting the CONFIG_MTD_UBI_FASTMAP variable to "y". After recompilation of the kernels the UBIFS images still have to be converted to Fastmap compatible images on first boot. This can be done on first boot by setting kernel boot parameter ubi.fm_autoconvert=1, after which it can be removed if successfully converted. Although I believe it isn't harmless if this parameter is left there, as it doesn't convert the ubifs image again if it already detects fastmap. See this presentation https://elinux.org/images/7/70/Opdenacker-boot-time-ELC-2014.pdf for some more information and benchmark.

Biktorgj commented 3 years ago

Given that I don't think I managed to resolve all the issues I was trying to and it's going to take more time, no use on delaying merging this