Live data from Hacker News

How Meta patches Linux at hyperscale

thenewstack.io

1–10 of 114 posts

Re: How Meta patches Linux at hyperscale

#2
Ksplice is the original live patching technology that got bought by Oracle and was later extended to user space programs while I worked there. It's a really neat technology that isn't made obsolete by the move to cloud, since you still don't want to have to restart the whole fleet at scale.

Re: How Meta patches Linux at hyperscale

#5

Never heard of this "hyperscale" concept before. How is this any different from... scaling?

Supermarkets and super cars aren't enough. We need hypermarkets and hyper cars to be current. So now we can’t just scale, I guess that’s for trucks, so to be current you need hyperscale.

Re: How Meta patches Linux at hyperscale

#6

Never heard of this "hyperscale" concept before. How is this any different from... scaling?

In general every order of magnitude brings new challenges. Companies running over a million servers have a lot of problems that smaller ones don't. Also they just have more room to amortize R&D.

Re: How Meta patches Linux at hyperscale

#9

Never heard of this "hyperscale" concept before. How is this any different from... scaling?

https://en.wikipedia.org/wiki/Hyperscale_computing

> In computing, hyperscale is the ability of an architecture to scale appropriately as increased demand is added to the system.

So yeah just scaling. I agree I've never heard the word "hyperscale" before and don't think we need that extra intensifier for a well-understood idea.

Re: How Meta patches Linux at hyperscale

#10
"Draining and un-draining hosts is hard."

I'd stop right there and fix that, because that's a bullshit reason. Cycling hosts in and out of service is easy unless you're not doing things properly.

The Linux kernel is simply not designed to be live patched and it's a total hack to try to do it, it will never work 100% of the time, always be a source of uncertainty, and always be expensive in terms of engineering work. Disaster will always be looming.

By contrast, fixing their system for taking hosts in and out of service, so that it's extremely robust and reliable would likely pay big dividends in reliability.

My guess would be that this approach is papering over organizational dysfunction. One team can patch all the kernels but one team can't make all the hosts support proper cycling in and out of service. And no one cares to fix it because there's no real incentive to do so. Only cool hacks and new projects are properly rewarded.

Post reply on HN