Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Meta’s renewed commitment to jemalloc

engineering.fb.com

Post reply on HN
Print view View original

171–180 of 259 posts

Re: Meta’s renewed commitment to jemalloc

#171

Post by xxs »

snackbroken wrote: post #125
adgjlsfhk1 wrote: post #91

Earlier quoted context omitted.

This only really ends up being a problem on windows. On systems with proper virtual memory setups, the cost of unused memory is very low (since the the OS can just page it out)

For video games it is pretty bad, because reading back a page from disk containing "freed" (from the application perspective, but not returned to the OS) junk you don't care about is significantly slower than the OS just handing you a fresh one. A 10-20ms delay is a noticeable stutter and even on an SSD that's only a handful of round-trips.

Overall if java hits the swap, it's a bad case. Windows is a like special beast when it comes to 'swapping', even if you don't truly needed it. On linux all (server) services run with swapoff.

Re: Meta’s renewed commitment to jemalloc

#172

Post by 1bpp »

alexgartrell wrote: post #146
adsharma wrote: post #144

Earlier quoted context omitted.

The patches were written in 2011 and published in 2012. They did what they were supposed to at the time. For the peanut gallery: this is a manifestation of an internal eng culture at fb that I wasn't particularly fond of. Celebrating that "I killed X" and partying about it. You didn't reply to the main point: did you benchmark a server that was running several days at a time? Reasonable people can disagree about whet…

For the peanut gallery more: I worked with both of these guys at Meta on this. The "servers are only on for a few hours" thing was like never true so I have no idea where that claim is coming from. The web performance test took more than a few hours to run alone and we had way more aggressive soaks for other workloads. My recollection was that "write zeroes" just became a cheaper operation between '12 and '14. A fun…

This is why I always read the comments here.

Re: Meta’s renewed commitment to jemalloc

#173

Post by Salgat »

eduction wrote: post #162
alexgartrell wrote: post #146

Earlier quoted context omitted.

For the peanut gallery more: I worked with both of these guys at Meta on this. The "servers are only on for a few hours" thing was like never true so I have no idea where that claim is coming from. The web performance test took more than a few hours to run alone and we had way more aggressive soaks for other workloads. My recollection was that "write zeroes" just became a cheaper operation between '12 and '14. A fun…

[flagged]

I'm personally appreciative of these comments. It's good that people make claims, be challenged, and both sides walk away with informative points being made. It's entirely possible both sides here are correct and wrong in their own way.

Re: Meta’s renewed commitment to jemalloc

#174

Post by jeffbee »

pram wrote: post #52

I used jemalloc recently for ComfyUI/Wan and it’s literally magic. I’m surprised it doesn’t come that way by default.

Allocators like that aren't the default for every process because they have higher startup costs. They are targeted to server workloads where startup cost doesn't matter, but it matters a lot if you're doing crud like starting millions of short-lived processes.

Re: Meta’s renewed commitment to jemalloc

#175

Post by jibal »

CyberDildonics wrote: post #154
cogman10 wrote: post #122

Earlier quoted context omitted.

> People typically do funky stuff with memory allocation because they have to This same dev did things like putting what he deemed as being large objects (icons) into weak references to save memory. When the references were collected, invariably they had to be reloaded. That was not the source of memory pressure issues in the app. I've developed a mistrust for a lot of devs "doing it because we have to" when it comes…

I'm not sure why you're rationale for how to deal with garbage collected memory is based on a guy that didn't know standard data structures and your own gut feelings. Any program that cares about performance is going to focus on minimizing memory allocation first. The difference between a GCed language like java is that the problems manifest as gc pauses that may or may not be predictable. In a language like C++ you…

Right? "I had this one contingent experience and I've built my entire world view and set of practices around it."

Re: Meta’s renewed commitment to jemalloc

#176

Post by kortex »

jjuliano wrote: post #66

I remember I was a senior lead softeng of a worldbank funded startup project, and have deployed Ruby with jemalloc in prod. There's a huge noticeable speed and memory efficiency. It did saved us a lot of AWS costs, compare to just using normal Ruby. This was 8 years ago, why haven't projects adopt it yet as de facto.

Usually lack of knowledge that such a thing exists, or just plain ol' momentum. Changing something long in production at established companies, even if there is a tangible benefit, can be a real challenge.

Re: Meta’s renewed commitment to jemalloc

#177

Post by asveikau »

adsharma wrote: post #142
asveikau wrote: post #140

Earlier quoted context omitted.

Maybe I'm misreading, but considering it OK to leak memory contents across a process boundary because it's within a cgroup sounds wild.

It wasn't any cgroup. If you put two untrusting processes in a memory cgroup, there is a lot that can go wrong. If you don't like the idea of memory cgroups as a security domain, you could tighten it to be a process. But kernel developers have been opposed to tracking pages on a per address space basis for a long time. On the other hand memory cgroup tracking happens by construction.

> across a process boundary

> within a cgroup

Note the complementary language usage here. You seem to have interpreted that as me writing that it didn't matter what cgroup they are in, which is an odd thing to claim that I implied. I meant within the same cgroup obviously.

Yes, you can read memory out of another process through other means.. but you shouldn't map pages, be able to read them and see what happened in another process. That's the wild part. It strikes me as asking for problems.

I was unaware of MAP_UNINITIALIZED, support for which was disabled by default and for good reason. Seems like it was since removed.

Re: Meta’s renewed commitment to jemalloc

#178

Post by genxy »

adsharma wrote: post #72

> We plan to deliver improvements to [..] purging mechanisms During my time at Facebook, I maintained a bunch of kernel patches to improve jemalloc purging mechanisms. It wasn't popular in the kernel or the security community, but it was more efficient on benchmarks for sure. Many programs run multiple threads, allocate in one and free in the other. Jemalloc's primary mechanism used to be: madvise the page back to th…

What metrics were improved by your patches?

Re: Meta’s renewed commitment to jemalloc

#180

Post by genxy »

alexgartrell wrote: post #146
adsharma wrote: post #144

Earlier quoted context omitted.

The patches were written in 2011 and published in 2012. They did what they were supposed to at the time. For the peanut gallery: this is a manifestation of an internal eng culture at fb that I wasn't particularly fond of. Celebrating that "I killed X" and partying about it. You didn't reply to the main point: did you benchmark a server that was running several days at a time? Reasonable people can disagree about whet…

For the peanut gallery more: I worked with both of these guys at Meta on this. The "servers are only on for a few hours" thing was like never true so I have no idea where that claim is coming from. The web performance test took more than a few hours to run alone and we had way more aggressive soaks for other workloads. My recollection was that "write zeroes" just became a cheaper operation between '12 and '14. A fun…

That is, wow, a story.

At what point did you realize how different fb engineering was from what you expected?

Post reply on HN