[r11] arter97 kernel for Poco F1

Not open for further replies.
Search This thread
Not open for further replies.

Top Liked Posts

  • There are no posts matching your filters.
  • 140

    arter97 kernel for Poco F1​

    /* Details */

    Latest CAF msm-4.9 kernel fully merged
    This kernel contains more cutting-edge changes from Qualcomm than the regular sdm845 tag
    Latest Linux 4.9 subversion merged
    Use CONFIG_HZ = 300
    - This changes context switching interval from 10ms to 3.33ms
    - Pixel used this for years and Google recommends other vendors to do the same for fewer jitters
    Memory management improved(from Pixel 2 & 3)
    Pixel's lowmemorykiller used
    Scheduler commits cherry-picked from Pixel 3
    Timer optimizations
    RTL8152/8153 USB LAN adapter support
    Permissive SELinux
    Passes SafetyNet
    Built with -O3 speed optimizations
    Built with latest GCC
    Westwood as default TCP network congestion control
    UFS optimizations
    Entropy hook on storage removed
    Latest mainline f2fs support with GC fixes
    CFQ I/O scheduler backported from mainline
    Systemless installation (the kernel itself doesn't touch /system or /vendor)
    Modules support disabled for lighter kernel
    WireGuard support
    Removed RTB(interrupt) logging entirely

    /* Development */

    I do not own a Poco F1.

    This was developed by sharing most of the bits from my OnePlus 6 and Razer Phone 2 kernel.
    I won't be doing device-specific changes to this kernel(e.g. improvements to the touch panel drivers) until I get my hands on an actual device.
    This also means this kernel is/will be developed conservatively.

    If you're interested in contributing to a fundraiser for me to get a Poco F1, please check post #2.

    /* f2fs */

    This kernel fully supports f2fs for /data and I encourage everyone to use f2fs with my kernel for better performance.
    See here as to why you might want f2fs.

    To use f2fs, download zip files from http://arter97.com/browse/f2fs

    Flash f2fs_tools_for_twrp.zip from TWRP. This won’t format your /data partition.
    This will replace TWRP's f2fs tools with the latest version and pass the correct parameter to mkfs.f2fs, which is necessary.
    This needs to be done everytime you enter TWRP, if you want to re-format to f2fs.

    After formatting, or flashing a new ROM or an OTA, /vendor’s fstab needs to be changed.
    Flash f2fs_fstab.zip to convert fstab to f2fs again. This won’t format your /data partition.

    /* Disclaimer */

    Your warranty is now void.
    I am not responsible for bricked devices, dead SD cards,
    thermonuclear war, or you getting fired because the alarm app failed. Please
    do some research if you have any concerns about features included in this kernel
    before flashing it! YOU are choosing to make these modifications, and if
    you point the finger at me for messing up your device, I will laugh at you. Hard. A lot.

    /* Thanks to */

    Tim Murray
    nathanchance - for android-linux-stable

    /* Instructions */

    You can use the zip file to flash the kernel from your existing TWRP recovery.
    If you don't have TWRP installed already, you can use the img file to flash the kernel directly from your PC via fastboot.

    Both methods will install both kernel and modified TWRP recovery.
    You can check if the modified TWRP is installed by looking at TWRP's version name.
    It should say "arter97".

    /* Downloads and links */

    Kernel source

    XDA:DevDB Information
    arter97 kernel for Poco F1, Kernel for the Xiaomi Poco F1

    Kernel Special Features:

    Version Information
    Status: Testing

    Created 2019-04-07
    Last Updated 2020-01-26
    There are soooo many misinformation regarding f2fs, but I don’t blame you. f2fs documentation sucks and there’s not much details on the internet except for its original paper.

    Here’s a discussion that went on a Telegram group. I’m sharing it here to correct some misconceptions regarding f2fs.

    F2FS is faster than ext4
    One of the reasons is the cache files that it generates
    Later these files remain as garbage Becoz no use
    No, those “invalid segments” generated from f2fs is not used as a cache in its lifetime. It’s a thing on LFS(Log-structured File System). LFS gives a lot of advantages to flash storage but the growth of invalid blocks is the biggest downside of LFS design. f2fs aimed to effectively solve this via GC.

    Soon they increase to a huge size
    And may corrupt your data
    It NEVER results in data corruption, it just causes a hit on write performance after free segments are gone. Then, GC must be triggered on every write requests.

    Kernels can enable background Gc flag
    Which may lead to a little slow performance
    I’m not sure I’d use “little slow performance” here, it’s quite the contrary. f2fs’ background GC detects idle time to run GC, which is by default set very conservatively to avoid any performance degradation when I/O request spikes while GC is running.
    My rapid GC disables background GC because it’s enough to clean-up invalid segments.

    F2FS itself just replacing EXT4, in fstab for example, isn't actually that much faster. Many many backend are up on the web to prove it.
    Traditional Linux I/O benchmarks don’t represent daily Android I/O workloads. Android I/O workloads are VERY different from traditional desktop/laptop’s workloads.

    The ability to turn off journaling safely in SQLite is so far the biggest advantage f2fs has over ext4. Check the piece I wrote on AnandTech for more details: https://www.anandtech.com/show/13474/the-google-pixel-3-review/2

    SSR also allows f2fs to reduce performance regression when the utilization is nearly full. This is indeed, very noticeable. If you compare side-by-side f2fs with ext4 both with more than 80% full, f2fs remains more responsive.

    However, when you use it configured a bit with nobarrier, etc. it can show a decent improvement (still not massive otherwise everyone would be using it).
    Not sure how much of an improvement you would start call “massive”. The LFS nature of f2fs allows fsync() to bypass barrier without sacrificing integrity, which uplifts the bottleneck in write performance. In practice, this gives about 5-6x improvements in write performance.

    Google enforces f2fs on Android Go devices. I think it’s a pretty good indication of “everyone is starting to use it”.

    Finally, it is no where near as stable as EXT4. It may have stabilised across the years but does not compare.
    I’m not gonna sugarcoat it. You’re correct.
    f2fs used to run into funky issues when a corner-case workload’s been thrown at it(which I’m yet to see in the recent year).

    But I’m genuinely curious why the heck people are saying f2fs is unstable for regular Android users to use it. I would LOVE to see some real data and fact behind someone saying f2fs is unstable.

    You won’t run into corner-case when you’re running Android. If any, it should be better than ext4 to its LFS nature.

    You heard of Btrfs before? Well it's considered still pretty unstable and corrupts data.
    btrfs aims to throw you every functions a file-system could possibly offer, which is why people say it’s unstable. btrfs/zfs is not comparable to f2fs.

    IIRC EXT4 has flags to lower wear and tear too and it's basically meaningless on UFS nowadays.
    Totally incorrect. Journalling itself gives ext4 a disadvantage about 30% over f2fs and its GC shenanigans. This is the main reason why f2fs is enforced on Android Go devices.
    Well if you’re gonna compare f2fs to ext4 without journalling, you don’t deserve to know these details.

    I'm saying just because you or even if this entire group didn't have issues with F2FS, that's not gonna give it the title of stable. Just look at Google's PXL3 implementation.
    What’s wrong with Pixel 3’s f2fs? I’m yet to see an issue caused from f2fs instability.

    F2FS is still missing things such as ICE support officially.
    Google used a proprietary implementation of ICE from CAF Partner tag
    Isn’t qcom’s implementation of ICE a mess anyways. This is not an issue of f2fs. f2fs just exposed multiple issues on qcom’s implementation of ICE.

    With other developers and my opinion I got to the conclusion that while F2FS is still unstable the only reason not to use is cause ICE F2FS isn't very ready yet.
    ICE on f2fs should be good if you have the latest CAF stuffs.
    r10 is up.
    I cooked up a separate Android 10 kernel since users seem to care.

    Novatek touch firmware updated to (by Akhil)
    Separate Android 10 kernel released
    Swap compressor backend(LZ4) updated
    LA.UM.8.3.r1-06100-sdm845.0 merged
    Linux v4.9.196 merged
    Wi-Fi drivers updated to
    Latest f2fs-stable merged
    I'm discontinuing Poco F1 development on XDA.

    Follow @arter97 on Twitter for status updates.