Announcement

Collapse
No announcement yet.

Microsoft's WSL2 Now Supports Memory Reclamation

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

  • Microsoft's WSL2 Now Supports Memory Reclamation

    Phoronix: Microsoft's WSL2 Now Supports Memory Reclamation

    Microsoft's Windows Insider Preview Build 19013 has introduced memory reclamation support for Windows Subsystem for Linux 2 (WSL2)...

    http://www.phoronix.com/scan.php?pag...eclaim-Support

  • #2
    I wonder why MS had to code that feature specifically for WSL2. Straight from the MS blog:

    We updated the Linux kernel in WSL2 to include this patch, and modified Hyper-V to support this page reporting feature
    If I've correctly understood, the feature is no different from common memory ballooning, which was present in Hyper-V and in the mainline Linux Kernel since year 2012 (look at hv_balloon linux kernel module to use that inside a Linux guest).

    So my doubts: why? And, even assuming that was actually needed, why a kernel patch (hardly committable upstream) instead of a new kernel module? Was the previous implementation too standard? Maybe this is the first step towards a new EEE?
    Last edited by lucrus; 10-31-2019, 07:21 AM.

    Comment


    • #3
      So, Microsoft takes ages to implement something that KVM with Linux guests did already. What a wonderful company.

      Comment


      • #4
        I wonder if this impacts performance in any way, that they did not reclaim memory before was one of the things that I suspected was why they had better performance on some loads than native Linux since they didn't had to go through the complicated mess that is memory allocation/deallocation like how e.g tcmalloc speeds up memory allocation.

        Comment


        • #5
          Originally posted by lucrus View Post
          I wonder why MS had to code that feature specifically for WSL2. Straight from the MS blog:

          If I've correctly understood, the feature is no different from common memory ballooning, which was present in Hyper-V and in the mainline Linux Kernel since year 2012 (look at hv_balloon linux kernel module to use that inside a Linux guest).

          So my doubts: why? And, even assuming that was actually needed, why a kernel patch (hardly committable upstream) instead of a new kernel module? Was the previous implementation too standard? Maybe this is the first step towards a new EEE?
          Except that ballooning in Hyper-V is a hit and miss. A prime example: I install Debian 10.1 in a Hyper-V VM. Memory 4GB, Min 512MB, Max 4GB. Allocated at start 4GB. So far ok... Compile some code, everything runs. Then after some time i compile code again and see the swap filling like crazy...

          And my memory is full ... I disable everything and see the pure debian only processes ( +-10 )... Yet, 3GB memory is used while the processes need to use at best 100MB. After some investigation i found out that Hyper-V ballooning has happend while i was away ( good ), and has reduced the memory consumption to 1.7GB but Debian is reporting a memory usage of 3GB+ and no process that uses that memory ( its the kernel, that is allocating this memory ).

          Even when you wait, the memory is never freed inside the Debian VM and forces your memory actions to swap ( great way to destroy SSDs if you did not notice this ). In other words, ballooning can be broken in the Linux Kernel.

          The WSL2 team also ran into this issue and thus they altered the custom WSL2 kernel to ensure they can really return the memory.

          Comment


          • #6
            Originally posted by F.Ultra View Post
            I wonder if this impacts performance in any way, that they did not reclaim memory before was one of the things that I suspected was why they had better performance on some loads than native Linux since they didn't had to go through the complicated mess that is memory allocation/deallocation like how e.g tcmalloc speeds up memory allocation.
            See the Youtube video at the end ( 5:20 mark ). WSL2 de-allocation only runs when your CPU is not in a loaded state. And it does not touch the Linux cached files ( it lets Linux handle that ). So its not going to de-allocate memory when your actually doing work that expands your memory.

            Comment


            • #7
              Originally posted by benjiro View Post

              Except that ballooning in Hyper-V is a hit and miss. [...]
              The WSL2 team also ran into this issue and thus they altered the custom WSL2 kernel to ensure they can really return the memory.
              I think it would still be better to fix the hv_balloon module (and Hyper-V if needed) than hacking a dirty patch into the kernel.

              Comment


              • #8
                Originally posted by benjiro View Post

                See the Youtube video at the end ( 5:20 mark ). WSL2 de-allocation only runs when your CPU is not in a loaded state. And it does not touch the Linux cached files ( it lets Linux handle that ). So its not going to de-allocate memory when your actually doing work that expands your memory.
                Sorry, I wasn't really clear. I was thinking about WSL1 where they ported the Linux Kernel API instead of running a real Linux Kernel, in some benchmarks here WSL1 was outperforming native Linux on the same hardware on some tasks where the kernel should have no or very small impact besides the memory allocation which is what made me think that perhaps they just handed out new memory like tcmalloc to speed things up (I don't use Windows so I have not tested WSL myself).

                Comment

                Working...
                X