Announcement

Collapse
No announcement yet.

Linux 5.14-rc4 Released With Change Following Some Broken Android Apps, Other Fixes

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux 5.14-rc4 Released With Change Following Some Broken Android Apps, Other Fixes

    Phoronix: Linux 5.14-rc4 Released With Change Following Some Broken Android Apps, Other Fixes

    Linux 5.14-rc4 is available today as a rather smooth update with nothing too worrisome but just a decent amount of fixes and nothing that is causing Linux creator Linus Torvalds to be frustrated...

    https://www.phoronix.com/scan.php?pa...4-rc4-Released

  • #2
    Something to note here is the insane level of work being done with BTRFS. I'd love to see 5.14's BTRFS benchmarked against other file systems in that kernel and against BTRFS of version 5.10 (most recent LTS kernel). I bet there would be some big swings just due to all the churn and optimization.

    Question for anyone who knows: do changes to io_uring impact file systems?
    Last edited by Mitch; 01 August 2021, 10:42 PM.

    Comment


    • #3
      Originally posted by Mitch View Post
      Something to note here is the insane level of work being done with BTRFS. I'd love to see 5.14's BTRFS benchmarked against other file systems in that kernel and against BTRFS of version 5.10 (most recent LTS kernel). I bet there would be some big swings just due to all the churn and optimization.
      Funny you say that, I was looking at those btrfs patches for 5.10 (just added 5.10 LTS support, see script here, line 630 for the btrfs 5.10 patches)

      You can now benchmark them yourself when you get the time. (put those 8c/16t to use, but consider the electricity usage as well).

      I highly consider "ccache" if you guys are not using it and are compiling stuff on your computer. ccache is compiler cache, if your build fails at 99%, it'll quickly fetch from cache instead of recompiling next time you bild, all automated so you don't even notice it.

      Anyways, to build the two kernels, use this:

      For 5.10: KERNEL_BASE_VER=5.10 KERNEL_PATCH_VER=5.10.55 KERNEL_SUB_VER=051055 ./build_kernel.sh
      For 5.14-rc4: KERNEL_SRC_URI="https://git.kernel.org/torvalds/t" KERNEL_SRC_EXT="tar.gz" KERNEL_BASE_VER=5.14 KERNEL_PATCH_VER=5.14-rc4 KERNEL_SUB_VER=051400rc4 ./build_kernel.sh

      Still some time left in the weekend, get to compiling. Cheeers and God speed

      Comment


      • #4
        Originally posted by perpetually high View Post

        I highly consider "ccache" if you guys are not using it and are compiling stuff on your computer. ccache is compiler cache, if your build fails at 99%, it'll quickly fetch from cache instead of recompiling next time you bild, all automated so you don't even notice it.
        I noticed it and, because of that, I don't trust ccache. Back when I built my own Android roms the ones built with ccache enabled always had random issues that the roms built without ccache never had. While anecdotal, the bad builds with and good builds without happened enough times in repeatable manners that I quit using ccache. Note that I was using a 100GB ccache because I have plenty of storage. IIRC, it's 2GB by default which isn't very much and won't cache a lot of stuff meaning you'll be refilling the cache if you switch between the kernel and something like Firefox or GCC.

        If you're only building the one project over and over again, ccache it up. If you're building multiple projects, even if they're related like with an Android rom, consider using an individual cache per project like this method on Gentoo.

        Comment


        • #5
          Originally posted by skeevy420 View Post

          I noticed it and, because of that, I don't trust ccache. Back when I built my own Android roms the ones built with ccache enabled always had random issues that the roms built without ccache never had. While anecdotal, the bad builds with and good builds without happened enough times in repeatable manners that I quit using ccache. Note that I was using a 100GB ccache because I have plenty of storage. IIRC, it's 2GB by default which isn't very much and won't cache a lot of stuff meaning you'll be refilling the cache if you switch between the kernel and something like Firefox or GCC.

          If you're only building the one project over and over again, ccache it up. If you're building multiple projects, even if they're related like with an Android rom, consider using an individual cache per project like this method on Gentoo.
          You're so right, and I've noticed the exact same thing but wasn't sure if it was me. Thanks for sharing. I'm gonna just ditch ccache as of today as I don't really need it anymore and I don't want unpredictable behavior from a intermediary fudging something up.

          I'd also argue it makes compilation slower because of the additional step of putting it into the compiler cache, as opposed to just compile the thing, and move on.

          Also, with all the Ryzens annd Intel chips having 8c/16t, it doesn't make as much sense to have ccache. If you're on a 2c/4t or 4c/4t, then maybe. I liked it also on projects like dolphin-emu, PPSSPP, dosbox-staging, etc, where say only 5 lines of code change, I don't need to compile 100% of the code just to capture the difference from the last commit.

          Lastly, another reason I don't like ccache is I can compile the same exact kernel twice and I don't get the same exact binary output on the .deb files it creates (I suppose I should just check the vmlinuz file). I've chocked it up to entropy and different small byte difference here and there in dates or something so I didn't look into it further, but I don't like that.

          Comment


          • #6
            Originally posted by perpetually high View Post

            You're so right, and I've noticed the exact same thing but wasn't sure if it was me. Thanks for sharing. I'm gonna just ditch ccache as of today as I don't really need it anymore and I don't want unpredictable behavior from a intermediary fudging something up.

            I'd also argue it makes compilation slower because of the additional step of putting it into the compiler cache, as opposed to just compile the thing, and move on.

            Also, with all the Ryzens annd Intel chips having 8c/16t, it doesn't make as much sense to have ccache. If you're on a 2c/4t or 4c/4t, then maybe. I liked it also on projects like dolphin-emu, PPSSPP, dosbox-staging, etc, where say only 5 lines of code change, I don't need to compile 100% of the code just to capture the difference from the last commit.

            Lastly, another reason I don't like ccache is I can compile the same exact kernel twice and I don't get the same exact binary output on the .deb files it creates (I suppose I should just check the vmlinuz file). I've chocked it up to entropy and different small byte difference here and there in dates or something so I didn't look into it further, but I don't like that.
            In regards to speed, depends if you're using a large or small cache and how fast the drive is (ssd or spinner). Spinners probably will be slower due to the cache read/write during compile. There's a reason we compile on /tmp as well as some ccache guides suggest /tmp-based locations (usually people doing the one package over and over again).

            The size, however, smaller probably will be slower regardless of storage medium because you'll use up all your cache which defeats the purpose of using ccache...instead of reusing the cache you'll keep filling it up over and over again, especially every time you switch projects, so you might not ever use any of it which is why I pointed out my large cache and the smaller default size it comes with as well as that per-package thing Gentoo can hack in. Simply put, the default 2GB might not be enough for some projects and isn't enough for multiple projects. If your ccache dir is maxed out you need to increase your ccache size limit or just set it to something stupid high like I did.

            Comment


            • #7
              Originally posted by skeevy420 View Post

              In regards to speed, depends if you're using a large or small cache and how fast the drive is (ssd or spinner). Spinners probably will be slower due to the cache read/write during compile. There's a reason we compile on /tmp as well as some ccache guides suggest /tmp-based locations (usually people doing the one package over and over again).

              If your ccache dir is maxed out you need to increase your ccache size limit or just set it to something stupid high like I did.
              Yeah, ccache defaults to 5GB and at times I've bumped it up to 10GB to fill up the cache as much as possible without evicting.

              That's a good point about compiling on /tmp, didn't think about that. Is that one of the benefits of using tmpfs on /tmp? Any improvements in caching or speed? Either way, I think ditching ccache is the right move, regardless of what machine you're on. Gonna leave it in my original post, but no longer recommending it (and I think that's why I've hesitated doing so before, now I know).

              Comment


              • #8
                Originally posted by perpetually high View Post

                Yeah, ccache defaults to 5GB and at times I've bumped it up to 10GB to fill up the cache as much as possible without evicting.

                That's a good point about compiling on /tmp, didn't think about that. Is that one of the benefits of using tmpfs on /tmp? Any improvements in caching or speed? Either way, I think ditching ccache is the right move, regardless of what machine you're on. Gonna leave it in my original post, but no longer recommending it (and I think that's why I've hesitated doing so before, now I know).
                5 and 2. Is that memory dyslexia? Jeez, I know it happens with reading, but memory too?!?

                Yes, that's the biggest benefit...that and not wearing out your SSD. Back in the HDD days tmpfs on /tmp was a godsend to have and, slightly related, was/is one of the reasons Linux works so well on crappy hardware. Major improvements in speed and caching. If you have a systemd based system you should already be using tmpfs on /tmp or /var/tmp. By default it should reserve 50% of your memory for that.

                Again, anectodally, ccache is fine if you're doing the one project over and over again like Dolphin. When doing multiple projects and sharing one cache with everything, that's how all my bad anecdotal experiences have occurred. It's tedious, but setting cache per project is the safest route if you want to keep using it. I've used it just fine for the one-off program since those Android days and have tried not to use mixed cache.

                That said, the Gentoo Handbook warns about using ccache due to numerous build issues and bug reports and suggests to first rebuild a package without ccache to see if that's the cause of errors....which basically mirrors our anecdotal experiences. If the Gentoo folks aren't the biggest supporters of it, that says a lot without saying a lot.

                Their warning is funny when coupled with real world usage: use too big of a cache and you risk using old code and getting errors; use too small of a cache and you defeat the purpose of ccache

                Comment


                • #9
                  Originally posted by skeevy420 View Post
                  That said, the Gentoo Handbook warns about using ccache due to numerous build issues and bug reports and suggests to first rebuild a package without ccache to see if that's the cause of errors....which basically mirrors our anecdotal experiences. If the Gentoo folks aren't the biggest supporters of it, that says a lot without saying a lot.

                  Their warning is funny when coupled with real world usage: use too big of a cache and you risk using old code and getting errors; use too small of a cache and you defeat the purpose of ccache
                  Hilarious, and thanks for all the insight.

                  Comment

                  Working...
                  X