Announcement

Collapse
No announcement yet.

Linux 6.2 Speeds Up A Function By 715x - kallsyms_lookup_name()

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

  • Linux 6.2 Speeds Up A Function By 715x - kallsyms_lookup_name()

    Phoronix: Linux 6.2 Speeds Up A Function By 715x - kallsyms_lookup_name()

    As a nice Christmas present, code merged today to the Linux 6.2 kernel speeds up a core kernel function by a factor of 715x...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    It's such a simple yet performant solution.

    Adding another array that contains index to the original one so that it can be sorted without affecting the order of the original array and provides significant speedup.

    Comment


    • #3
      Originally posted by NobodyXu View Post
      It's such a simple yet performant solution.

      Adding another array that contains index to the original one so that it can be sorted without affecting the order of the original array and provides significant speedup.
      when i see the phoronix benchmark graph , that is when i will believe

      Comment


      • #4
        That's absolutely wonderful!
        I wish this was backported to 6.1, especially since it's so simple.

        Comment


        • #5
          Originally posted by onlyLinuxLuvUBack View Post

          when i see the phoronix benchmark graph , that is when i will believe
          Changes to one single function is usually benchmarked using micro benchmark, that will highlight its impact.
          Measuring the whole system performance for a certain task might not be noticeable given that there are hundreds or thousands of other functions called.

          The changes to this function definitely improve the performance significantly with slightly larger kernel elf size.
          This is because it's changed from a linear search to binary search, O(n) to O(log(n)) and is now becoming much faster consider that the kernel has a lot of symbols.
          You don't need a benchmark to know that this changes would improve the performance of that single function.

          Comment


          • #6
            Originally posted by NobodyXu View Post

            Changes to one single function is usually benchmarked using micro benchmark, that will highlight its impact.
            Measuring the whole system performance for a certain task might not be noticeable given that there are hundreds or thousands of other functions called.
            The obvious question, which is not answered in the article, would be: when is this function actually used? Just during boot-up? Or permanently while the kernel is running? When modules are loaded?

            A 700x performance gain is great. Yet, if this function is only called e.g. on kernel startup, it doesn't really matter that much.
            Last edited by oleid; 14 December 2022, 02:53 AM.

            Comment


            • #7
              Originally posted by oleid View Post

              The obvious question, which is not answered in the article, would be: when is this function actually used? Just during boot-up? Or permanently while the kernel is running? When modules are loaded?

              A 700x performance gain is great. Yet, if this function is only called e.g. on kernel startup, it doesn't really matter that much.
              I'm not sure about that.

              Comment


              • #8
                Originally posted by oleid View Post

                The obvious question, which is not answered in the article, would be: when is this function actually used? Just during boot-up? Or permanently while the kernel is running? When modules are loaded?

                A 700x performance gain is great. Yet, if this function is only called e.g. on kernel startup, it doesn't really matter that much.
                I do agree,but improvements doesn't have to be always huge: many small improvements add up​ and in the long time makes the difference.
                Also, when someone find a way to solve a problem in a smarter/better way is in itself a good news.

                Comment


                • #9
                  Originally posted by cynic View Post

                  I do agree,but improvements doesn't have to be always huge: many small improvements add up​ and in the long time makes the difference.
                  Also, when someone find a way to solve a problem in a smarter/better way is in itself a good news.
                  Oh, don't get me wrong. I fully agree, as long as the code is still maintainable. I was just wondering about the bigger picture.

                  Comment


                  • #10
                    Originally posted by oleid View Post

                    Oh, don't get me wrong. I fully agree, as long as the code is still maintainable. I was just wondering about the bigger picture.
                    the bigger picture is just catastrophic due to the security mitigations of the last years

                    Comment

                    Working...
                    X