Announcement

Collapse
No announcement yet.

Gentoo Offers Up New Easy Kernel Options

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

  • #11
    Originally posted by trilean View Post

    EDIT: And version bumps or even creating new packages is super easy. Usually it's enough to rename an ebuild for a version bump, and writing custom ebuilds isn't very hard either.
    tbh writing ebuilds is more complex than debs or rpms.
    still easy to learn and master though

    but...well... thats because of use-flags. which are the biggest gift i ever got

    Comment


    • #12
      Originally posted by NotMine999 View Post

      The problem with Gentoo "ricers" is this: They make such claims but provide no standardized testing proof to back it up.

      By "standardized" I mean this: "A broad set of many tests that you can run across multiple systems where the test setups are consistent across all systems and the test outputs are presented in a standard format for easy comparison."

      I hear Phoronix has a great test suite that should run on Gentoo. Let's see the Gentoo "ricers" use it to compare the performance of these prebuilt kernels to their best efforts at "ricing a kernel".
      While I am not using Gentoo, performance was the main reason to learn how to optimize and build my own kernel with aggressive compiler flags. And while not standardized in your sense, my testing with a CPU bound game benchmark shows major differences in fps (to be exact more than double in Manjaro 20.1, Xeon 2678 V3 with a Vega 56 with Company of Heroes 2 from 24 to 53 in the in-game benchmark with the Xanmod-Kernel, some basic tuning in the config plus the PDS scheduler and march=native with GCC 10.2 - with Tumbleweed, a custom Kernel without PDS and using DXVK I nearly got within 10% of the Windows performance in this game on my hardware). This is huge and makes me wonder why the PC ecosystem as a whole hasn't found a way to better make use of the advancements in CPU and compiler technologies in an automated way or with highly optimized distribution packages for several important platforms.

      Comment


      • #13
        Originally posted by NotMine999 View Post

        The problem with Gentoo "ricers" is this: They make such claims but provide no standardized testing proof to back it up.

        By "standardized" I mean this: "A broad set of many tests that you can run across multiple systems where the test setups are consistent across all systems and the test outputs are presented in a standard format for easy comparison."

        I hear Phoronix has a great test suite that should run on Gentoo. Let's see the Gentoo "ricers" use it to compare the performance of these prebuilt kernels to their best efforts at "ricing a kernel".
        I recommend you to study this https://github.com/graysky2/kernel_gcc_patch

        Comment


        • #14
          Originally posted by NotMine999 View Post

          The problem with Gentoo "ricers" is this: They make such claims but provide no standardized testing proof to back it up.

          By "standardized" I mean this: "A broad set of many tests that you can run across multiple systems where the test setups are consistent across all systems and the test outputs are presented in a standard format for easy comparison."

          I hear Phoronix has a great test suite that should run on Gentoo. Let's see the Gentoo "ricers" use it to compare the performance of these prebuilt kernels to their best efforts at "ricing a kernel".
          You will loose that argument, there are readilly avaiable benches of kernels built with various optimizations, including LTO on GentooLTO's github issue tracker. Google itself is pushing for upstreaming of LTO into kernel's build system since they've been building such kernels for their Pixel line, for years. Fedora started LTOing their packages recently too. Apparently smarter people than you decided that "ricing" is worth it.
          Last edited by Tvashtar; 16 September 2020, 11:45 AM.

          Comment


          • #15
            This is a good thing. I usually copy my kernel config from another distro and tweak it for Gentoo. With a binary kernel you can get your system up faster then modify it's config if you want to roll your own. Nice.

            In theory Gentoo could be pretty snappy maybe not so much in optimizations but in disabling unused features (like all of systemd) and making the system just do less. In practice unless you're doing LTO or a lot of fine (and potentially stability affecting) tuning it not really any faster than anything else.

            FreeBSD is in the same boat with ports also, a lot of tuning can be done there. (tho very little of it is tested)

            Edit: Now that there is a real official kernel configuration would it be possible for that to be genkernel aware and update your custom kernel config via etc-update so you get a diff and pick up new changes? In Gentoo it's hard to track new features in the kernel..
            Last edited by k1e0x; 16 September 2020, 12:55 PM.

            Comment


            • #16
              Originally posted by NotMine999 View Post
              The problem with Gentoo "ricers" is this: They make such claims but provide no standardized testing proof to back it up.
              This assumes they care about proof in the first place. Ricing has been sufficiently evidenced to be a byproduct of lollygagging.

              Comment


              • #17
                I think this is a good development, to help and open up Gentoo to a wider audience, as long as the keep the gentoo-sources and vanilla sources.

                I prefer the gentoo-sources or vanilla-sources myself for a variety of reasons.

                1. Smaller in size due to the disablement of unnecessary features;
                2. Faster boot times due to the disablement of unnecessary features due to less features that need to be loaded;
                3. Reduced attack vectors due to the disablement of unnecessary features which could potentially contain exploitable code;
                4. Stability due to the disablement of unnecessary features which could potentially cause a crash;
                5. An optional, but not a main reason: The fact that it's compiled with -march=native and -O2 (when you select the correct processor and have the experimental USE flag enabled), even though the speed benefits are minimal.
                6. Some in-kernel tweaks applied to the RCU scheduler and the I/O scheduler which are beneficial in some of my use cases.

                The bzImage on my AMD Ryzen 2700X system is only 5,6MB in size, due to all of unnecessary features and on my Lenovo ThinkPad P52 only 9,8MB compared to a Ubuntu image being an average of 12MB and that excludes an additional initrd, which comes shipped by default with most distributions with an average of 78MB which I simply don't need.

                Comment


                • #18
                  I used to use Gentoo, specifically for it's ability to tweak the dependencies of packages; performance was never my "thing". My primary focus was on a very lean system with a CLI interface that had as little binary bloat as possible.

                  What I liked about Gentoo package dependency tweaking was learning how plain vanilla most packages are in other distributions. In distros other than Gentoo I'd want to load package "X" but the package manager used by that distro would come and say, "but you gotta download this kitchen sink to go with it". Geez! I thought binary bloat only happened in Micro$haft OS. Yes, it opened my eyes to how bloated most Linux packages are so that they can support the widest range of users while minimizing the packaging hassles for the distro.

                  What I disliked about Gentoo was the amount of time I could spend tweaking a setup to minimize the unwanted dependencies, usually for app features I did not want or need, only to have to work through the optimization exercise again with the next updates to the packages I wanted. "wash, rinse, repeat" is not my idea of system management.

                  What finally drove me away from Gentoo was the lack of response from the Gentoo bug tracking process over issues that I documented, sometimes in very meticulous detail that went beyond what the Gentoo bug tracking system requested of users when posting a bug. If Gentoo's own developers show no interest in the reports of well-documented & repeatable bugs, then why should I bother using Gentoo. I shared those thoughts with a person I know that works with Gentoo developers, and he responded, "Yes I know. It's a problem."

                  Now if anyone from the Gentoo project contacts me their emails are immediately bit-canned.

                  Comment


                  • #19
                    Do you still have the same requirements you mentioned in your post NotMine999?

                    What are you running nowadays?

                    Comment


                    • #20
                      Originally posted by Serafean View Post
                      I am a fan of these packages: It installs the sources, and also builds them (like for the rest of the system)! All the while allowing the user to configure the build using savedconfig. All I need is to find how to create a postinstall hook to take care of some more manual stuff, and the last manual update is gone.
                      The complete binary package is welcome for newcommers, as the build can take quite some time.
                      ++

                      My words exactly.

                      Comment

                      Working...
                      X