Announcement

Collapse
No announcement yet.

Facebook Engineer Proposing New Slab Memory Controller For Linux - Saves Lots Of RAM

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

  • #11
    Originally posted by M@GOid View Post
    Memory manufacturers hate him.
    If the patch proves to be effective.. we wil love him!

    Comment


    • #12
      Originally posted by tildearrow View Post
      3 typos?! Michael, you need to take some sleep
      Well, more actually.
      I really hope all the "Mb"'s in the article are "MB"'s :P
      They are, else the context makes absolutely no sense.. But it's a quite big mistake for a someone that deep into tech as Michael.

      He should take some rest

      Comment


      • #13
        So will I notice reduced memory usage of my LEMP stack + Redis running on a VPS? Or will just my host see lower overall memory usage on the hypervisor?

        Comment


        • #14
          SLAB allocators come with tradeoffs. Don't tell me there are no tradeoffs.
          You just don't reduce memory usage without side effects like fragmentation, cache abuse, cache-line abuse or something else.
          SLAB, SLOB and SLUB all have their ups & downs.
          I'd easily trade less memory efficiency for better execution and cache efficiency.
          All load types are not created the same either.

          Comment


          • #15
            Originally posted by milkylainen View Post
            SLAB allocators come with tradeoffs. Don't tell me there are no tradeoffs.
            You just don't reduce memory usage without side effects like fragmentation, cache abuse, cache-line abuse or something else.
            SLAB, SLOB and SLUB all have their ups & downs.
            I'd easily trade less memory efficiency for better execution and cache efficiency.
            All load types are not created the same either.
            This is not about SLAB allocators as such, but about how they've been used. With current design slab pages are exclusive for each cgroup. This was not much of an issue originally because cgroups were opt-in and not used much. Nowadays they are used much more extensively and thus result in low memory utilization.

            Comment


            • #16
              Originally posted by marlock View Post
              Is there no security implication to sharing this between cgroups?
              all kernel memory is shared from security pov. this is more like "use unused space of other cgroup" than sharing

              Comment


              • #17
                Originally posted by milkylainen View Post
                SLAB allocators come with tradeoffs. Don't tell me there are no tradeoffs.
                subj is cgroup controller, not memory allocator

                Comment


                • #18
                  Originally posted by M@GOid View Post
                  Memory manufacturers hate him.
                  But since you can now run more licensed software in the same amount of RAM, some software manufactories will love him for the extra licenses thus gained. And they charge more per month than a memory module costs, so yay.

                  Comment


                  • #19
                    Omg, facebook people are so boring.

                    Just fix it already, so they can piss off and go back to Epsteining on kids with their LifeLog CIA/DARPA horseshit.

                    Comment


                    • #20
                      Originally posted by pal666 View Post
                      subj is cgroup controller, not memory allocator
                      Ok. My bad. The apparently fubared quick readup was interpreted as as "fixing the SLAB allocator".

                      Comment

                      Working...
                      X