Announcement

Collapse
No announcement yet.

Linus Torvalds Cleans Up The x86 Memory Copy Code For Linux 6.4

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

  • Linus Torvalds Cleans Up The x86 Memory Copy Code For Linux 6.4

    Phoronix: Linus Torvalds Cleans Up The x86 Memory Copy Code For Linux 6.4

    In recent years Linus Torvalds hasn't had the time to write too much original new code for the Linux kernel himself with these days mostly managing developers, providing insightful mailing list posts, and reviewing code for merging into the kernel tree along with related tasks. For Linux 6.4 though he did manage to write up some new code...

    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
    If I write a program that calls memcpy, will this new kernel code improve the performance of that?

    Comment


    • #3
      Originally posted by stompcrash View Post
      If I write a program that calls memcpy, will this new kernel code improve the performance of that?
      I don't think so. The memcpy() you call from user space code resides in glibc, not in the kernel.

      Comment


      • #4
        Originally posted by stompcrash View Post
        If I write a program that calls memcpy, will this new kernel code improve the performance of that?
        No, since it doesn't enter kernel mode. glibc or whatever other C library you're using will have to get patched for it.

        I don't know why it took Intel literally decades to make these instructions fast at all times. The CPU knows about its state best, so if an instruction conveniently tells the CPU what it wants to do (like copy memory, or scan memory), the CPU can optimize it the best at runtime. And such things are used everywhere so it's not like it's not a common case to spend transistors on. Jesus Christ.

        Comment


        • #5
          Originally posted by Weasel View Post
          I don't know why it took Intel literally decades to make these instructions fast at all times. The CPU knows about its state best, so if an instruction conveniently tells the CPU what it wants to do (like copy memory, or scan memory), the CPU can optimize it the best at runtime. And such things are used everywhere so it's not like it's not a common case to spend transistors on. Jesus Christ.
          And it is crazy, that we for decades have had to call a library function instead of direct language/compiler support...

          Comment


          • #6
            Originally posted by Veto View Post
            And it is crazy, that we for decades have had to call a library function instead of direct language/compiler support...
            And you'll still do it via library call in user space unless you want a very non-portable binary.

            Comment


            • #7
              So what does this realy do it optimizes some macros that probably get used very often in the kernel or by userspace calls ?

              Is it for easy Programming or Performance would be cool to get some input on this.

              Comment


              • #8
                I think both? The number of lines has reduced, it looks like the number of code paths as well. For newer systems it may be an improvement in performance as well. I am not entirely sure that full optimisation is preserved for e.g. the P4, but maybe that is handled as one of the "alternatives*.

                Comment

                Working...
                X