• tetris11@lemmy.ml
    link
    fedilink
    arrow-up
    27
    ·
    8 days ago

    (quick search)
    A TLB flush is used when the virtual memory address mappings to physical memory addresses need to be updated.
    This patch reduces the number of flushes needed to keep the memory current by a factor of 512, by using some fancy buffering.

    Sounds good, wonder if I’ll notice it once it’s mainline

    • DaPorkchop_@lemmy.ml
      link
      fedilink
      arrow-up
      12
      ·
      edit-2
      8 days ago

      This probably won’t make much difference unless your application is frequently adding and removing large numbers of page mappings (either because it’s explicitly unmapping memory segments, or because pages are constantly being swapped in and out due to low system memory). I would suspect that the only things which would really benefit from this under “normal” circumstances are some particularly I/O intensive applications with lots of large memory mappings (e.g. some webservers, some BitTorrent clients), or applications which are frequently allocating and deallocating huge slabs of memory.

      There might be some improvement during application startup as all the code+data pages are mapped in and the memory allocator’s arenas fill up, but as far as I know anonymous mappings are typically filled in one page at a time on first write so I don’t know how relevant this sort of batching might be.

      • tetris11@lemmy.ml
        link
        fedilink
        arrow-up
        5
        ·
        8 days ago

        I sometimes have to mount large swap files to assist with some concurrent tasks. Would this patch help here?

        • DaPorkchop_@lemmy.ml
          link
          fedilink
          arrow-up
          4
          ·
          8 days ago

          This is specific to page reclamations, which only occur when the kernel is removing a block of memory from a process. VMs in particular pretty much never do this; they pin a whole ton of memory and leave it entirely up to the guest OS to manage. The JVM also rarely ever returns heap memory to the kernel - only a few garbage collectors even support doing so (and support is relatively recent), and even if you have it configured correctly it’ll only release memory when the Java application is relatively idle (so the performance hit isn’t noticeable).