Computing Performance on the Horizon
brendangregg.com
Computing Performance on the Horizon
1–10 of 75 posts
Re: Computing Performance on the Horizon
#2A delightful set of slides and references that tickles many of my pet topics. In particular, one I’d love to hear more about is why so many deployments are still choosing 2-socket servers by default when managing them is such a pain in the neck and the performance when you do it badly is so poor. Live the life of the future, today: choose single sockets!
Re: Computing Performance on the Horizon
#3Nice talk , covers a lot of base . He predicts Unikernels are dead, Containers will keep growing and lighthweight vms will take over after that.
Re: Computing Performance on the Horizon
#4A delightful set of slides and references that tickles many of my pet topics. In particular, one I’d love to hear more about is why so many deployments are still choosing 2-socket servers by default when managing them is such a pain in the neck and the performance when you do it badly is so poor. Live the life of the future, today: choose single sockets!
In world where most work loads are containerized, and where each container can be pinned to numa region doesn't it really matter?
Re: Computing Performance on the Horizon
#5Some random contemporary musings, that touch some of these topics: I really hope we have a rad eBPF based QUIC/HTTP3 front-end/reverse-proxy router in the next 5 years.
QUIC is so exciting and I just want it to be both fast & a supremely flexible way for a connection from a client to talk to a host of backend services. We'll definitely see some classic userland based approaches emerge, but gee, really hungry for
For context, I was at the park two days ago, thinking about replacing a Node timesync[1] over websockets thing with a NTP-over-WebTransport (QUIC) implementation. There werent any H3 front-ends (which I kind of need because I just have some random colo & VPS boxes), and even if there were I was worried about adding latency (which a BPF based solution would significantly reduce, while letting me re-use ports 80/443).
Especially as we see more extreme-throughput/HBM memory systems arrive, it's just so neat that we have a multiplexed transport protocol. Figuring out how to use that connection (semi stateless "connection", because QUIC is awsome) to talk to an array of services is an ultra-interesting challenge, and BPF sure seems like the go-to tech for routing & managing packets in the world today. QUIC, with it's multiplexing, adds the complexity that it is now subpackets that we want to route. I hope we can find a way to keep a lot of that processing in the kernel.
Re: Computing Performance on the Horizon
#6A delightful set of slides and references that tickles many of my pet topics. In particular, one I’d love to hear more about is why so many deployments are still choosing 2-socket servers by default when managing them is such a pain in the neck and the performance when you do it badly is so poor. Live the life of the future, today: choose single sockets!
In world where most work loads are containerized, and where each container can be pinned to numa region doesn't it really matter?
Does any container runtime/orchestrator perform this optimization yet? Why wait?
Re: Computing Performance on the Horizon
#7A delightful set of slides and references that tickles many of my pet topics. In particular, one I’d love to hear more about is why so many deployments are still choosing 2-socket servers by default when managing them is such a pain in the neck and the performance when you do it badly is so poor. Live the life of the future, today: choose single sockets!
In world where most work loads are containerized, and where each container can be pinned to numa region doesn't it really matter?
k8s, by default, is oblivious to NUMA topology. You have to enable unreleased features and configure them correctly, which is the unwanted complexity to which I referred earlier. Simply aligning your containers to NUMA domains does not solve the problem that your arriving network frames or your NVMe completion queues can still be on the wrong domain. Isn't it simpler to just have 1 socket and not need to care? The number of cores available on a single socket system is pretty high these days, and in general the 1S parts are cheaper and faster.
Re: Computing Performance on the Horizon
#8Earlier quoted context omitted.
In world where most work loads are containerized, and where each container can be pinned to numa region doesn't it really matter?
Does any container runtime/orchestrator perform this optimization yet? Why wait?
Kernel scheduling is NUMA aware and will localize workloads.
Threads will mostly have their RAM on the sticks local to their node. The core the thread is delegated to is also more likely to be the core local to the disk or NIC being used for IO.
This is at least my experience, though I am no expert.
Re: Computing Performance on the Horizon
#9A delightful set of slides and references that tickles many of my pet topics. In particular, one I’d love to hear more about is why so many deployments are still choosing 2-socket servers by default when managing them is such a pain in the neck and the performance when you do it badly is so poor. Live the life of the future, today: choose single sockets!
Rack space can be quite expensive.
Sometimes you need a lot of computing power in one or two rack units.
Would be interested in what the management pains are. I agree that 2 socket machines require more thought in a lot of scenarios, especially IO heavy workloads.
Re: Computing Performance on the Horizon
#10Slide 26 is interesting - arguing that cloud providers have an advantage for future CPU design since they can analyze so many real world customer workloads directly.
In previous roles I have worked with CPU vendors who have been very keen on getting access to profiling data from our workloads for design optimization, and lamenting the fact that it was hard to get such data and they were often limited to synthetic benchmark workloads when tuning new designs.
So this argument does sound like a valid one, and does imply AWS etc will have significant advantages in future designs.