Announcement

Collapse
No announcement yet.

Memory Folios Looks For Inclusion In Linux 5.16

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

  • Memory Folios Looks For Inclusion In Linux 5.16

    Phoronix: Memory Folios Looks For Inclusion In Linux 5.16

    After memory folios failed to make it into Linux 5.15, this low-level change to the kernel memory management code that has possible performance implications is looking to land for Linux 5.16...

    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 means possible performance benefits possible

    Michael is it possible to quote but pass the minimum message length of 5 characters restriction?

    Comment


    • #3
      I'm going to be that person... Aside from the pretty anemic realistic performance gains, it's not enough to say "it doesn't harm performance", what people should also be asking is what the real and theoretical security implications are. We are long past the point where performance is our only concern about such a far reaching patch set.

      Comment


      • #4
        Originally posted by er888kh View Post


        Michael is it possible to quote but pass the minimum message length of 5 characters restriction?
        Nope, unless you post an image.

        You could type something like "chars" or "Typo:" instead.

        Comment


        • #5
          As there were heated discussions on the LKML over the last patchset, I hope the dust has settled for the 5.16 release cycle.

          Comment


          • #6
            Call me when it has support for ext4...

            Comment


            • #7
              Originally posted by stormcrow View Post
              I'm going to be that person... Aside from the pretty anemic realistic performance gains, it's not enough to say "it doesn't harm performance", what people should also be asking is what the real and theoretical security implications are. We are long past the point where performance is our only concern about such a far reaching patch set.
              Are there known security risks with these particular patches?

              Comment


              • #8
                Originally posted by ms178 View Post
                As there were heated discussions on the LKML over the last patchset, I hope the dust has settled for the 5.16 release cycle.
                People seem to want to cram a lot of features into folios to make more major cleanups of MM. This is foolish, especially in MM.

                The folios code by itself does a cleanup of MM and eliminates a whole category of bugs. It then also comes with tangible performance improvements.

                If there are other things to be fixed, those changes can be layered on top, given the foundation of cleaner code Folios will provide. This is not an external userspace API and can be refined in the future if needed.

                Comment


                • #9
                  Wow, I was sort of assuming that Jens Axboe was already tuning atop these, but it sounds unlikely. At least we can probably look forward to even more IOPS, in future kernels!

                  Comment


                  • #10
                    Originally posted by stormcrow View Post
                    I'm going to be that person... Aside from the pretty anemic realistic performance gains,
                    10% performance improvement on a I/O-heavy workload is not anemic! It's not trivial to get gains like that. You cannot sit back and wait for a single optimization that delivers 90% performance improvement. The big performance numbers are usually the sum of many small optimizations. Case in point would be Axboe's branch, which contains lots and lots of mostly little optimizations.

                    Originally posted by stormcrow View Post
                    it's not enough to say "it doesn't harm performance", what people should also be asking is what the real and theoretical security implications are.
                    Do you have concerns based on your understanding of the changes, or are you just raising the spectre of security implications somewhat reflexively?

                    Based on the high-level description, it seems no better or worse for security than before. It sounds like the traditional approach is an abstraction failure, which this fixes. To the extent that it simplifies existing code, it could turn out to be an indirect win for security.

                    Comment

                    Working...
                    X