Today I'm getting into cgroups for my next article.
The last one was about namespaces, which decide what a process can see. Cgroups decide how much it can use.
One thing that is kinda surprising is how you interact with cgroups, through the filesystem, generating a new cgroup is as easy as running a "mkdir" command. And limiting the number of processes just an "echo" command.
I'll talk about the cgroups, the controllers, and how they are shaped and access in the kernel.
The article will be available this Monday.
If you want these articles directly in your inbox? Subscribe to the newsletter: internals-for-interns.com/newsletter/
#Linux #Containers #Cgroups
The last one was about namespaces, which decide what a process can see. Cgroups decide how much it can use.
One thing that is kinda surprising is how you interact with cgroups, through the filesystem, generating a new cgroup is as easy as running a "mkdir" command. And limiting the number of processes just an "echo" command.
I'll talk about the cgroups, the controllers, and how they are shaped and access in the kernel.
The article will be available this Monday.
If you want these articles directly in your inbox? Subscribe to the newsletter: internals-for-interns.com/newsletter/
#Linux #Containers #Cgroups
1
8
72
1,758
Jesús Espino retweeted
If you write programs in Go, then take the following survey from Go core developers. This should help evolving Go in the correct direction (hint: stop complicating the syntax, focus on the simplicity and the performance).
The 2026 Go Developer Survey is open! Help set Go’s priorities for next year by telling us how you use Go and where it could be better.
⏱️ 10–20 minutes
📅 Open through November 3
blink.qualtrics.com/jfe/form/SV_ba…
#golang
5
10
113
5,089
A good episode on Tech Talks where we were talking about performance optimizations. My main take is, micro-optimizations are the cherry on top, but the performance has to come from the design and the good selection of needs and trade offs.
Great tech talk on why VictoriaLogs is so resource efficient and fast!
@jespinog explains why Go is good for writing programs optimized for high performance and low resource usage.
youtube.com/live/2YQVgB3iU…
Here is a text version of the talk - victoriametrics.com/blog/go-logs-a…
0
1
23
777
In 2017, I started learning Go, mostly from curiosity. After working some years for Mattermost, I learnt enough to start sharing that knowledge with the community. Today I’m honored to share that I’ve been recognized as a @GoogleDevExpert in Go.
This wouldn’t have happened involved in my own process, from the extremely welcoming Go community, to my companies, @kaleidosnet, @Mattermost, @ona_hq, and now @VictoriaMetrics, that has been always supportive and helping me to contribute back to the community.
The GDE program is about sharing knowledge, so, there is not going to change much from my side, except that I'll have even more support to keep sharing with you what I learn in Go.
#golang #GoogleDeveloperExpert #GDE #Go
This wouldn’t have happened involved in my own process, from the extremely welcoming Go community, to my companies, @kaleidosnet, @Mattermost, @ona_hq, and now @VictoriaMetrics, that has been always supportive and helping me to contribute back to the community.
The GDE program is about sharing knowledge, so, there is not going to change much from my side, except that I'll have even more support to keep sharing with you what I learn in Go.
#golang #GoogleDeveloperExpert #GDE #Go
31
27
273
5,941
Jesús Espino retweeted
If you aren't familiar with VictoriaLogs data model yet, then this clear video explainer from @func25 is for you!
youtube.com/watch?v=ZM6rUT…
youtube.com/watch?v=ZM6rUT…
0
7
49
2,096
My article about SIMD and Go is out!
In this one I explain how one CPU instruction can work on 8 numbers at once, and how you can now use that from plain Go with the experimental simd/archsimd and simd packages.
My intention with this post is to explain in simple terms how SIMD works at CPU level, to give you the mental model on how to use it, and then give you enough information about how you use it from Go to start working with it.
You can read it here: internals-for-interns.com/posts/go-simd/
#Go #SIMD
In this one I explain how one CPU instruction can work on 8 numbers at once, and how you can now use that from plain Go with the experimental simd/archsimd and simd packages.
My intention with this post is to explain in simple terms how SIMD works at CPU level, to give you the mental model on how to use it, and then give you enough information about how you use it from Go to start working with it.
You can read it here: internals-for-interns.com/posts/go-simd/
#Go #SIMD
1
21
140
9,862
Jesús Espino retweeted
#Go Fans!
The Data Race That Wasn't a Bug (and the One That Was)
The Go race detector found a race condition within the HTTP client that caught us by surprise, so the team dug into it and found two interesting things. If we found this race in two places, one of the races, in our case, was not a problem; it could be, but not in our case, so we didn't fix it. However, the second one actually was a bug, so we fixed it. If you want to know the details and understand why fixing it was the right choice for us, and why fixing the second one was needed. Check out the latest @jespinog blog post. hubs.li/Q04zQPXS0
The Data Race That Wasn't a Bug (and the One That Was)
The Go race detector found a race condition within the HTTP client that caught us by surprise, so the team dug into it and found two interesting things. If we found this race in two places, one of the races, in our case, was not a problem; it could be, but not in our case, so we didn't fix it. However, the second one actually was a bug, so we fixed it. If you want to know the details and understand why fixing it was the right choice for us, and why fixing the second one was needed. Check out the latest @jespinog blog post. hubs.li/Q04zQPXS0
0
2
18
756
My article about Linux Namespaces is out.
I start by creating a new namespace for the hostname by hand and explore all the way down to the kernel structures that makes it possible.
At the end, the answer is pointers. Each process has pointers to the namespaces that it belongs to, and when the kernel needs to find something asked by this process, follow those pointers and the response comes from those namespaces.
I focused in the uts namespace (hostname) and also mention the time namespace, because they are the simplest ones, but the concepts apply to the others.
Read it here: internals-for-interns.com/posts/linux-ke…
#Linux #Namespaces
I start by creating a new namespace for the hostname by hand and explore all the way down to the kernel structures that makes it possible.
At the end, the answer is pointers. Each process has pointers to the namespaces that it belongs to, and when the kernel needs to find something asked by this process, follow those pointers and the response comes from those namespaces.
I focused in the uts namespace (hostname) and also mention the time namespace, because they are the simplest ones, but the concepts apply to the others.
Read it here: internals-for-interns.com/posts/linux-ke…
#Linux #Namespaces
3
14
112
11,263
Today I'm investigating Linux namespaces, the feature that makes one machine look like several and it is a fundamental part of the containers technology.
You can run `sudo unshare --uts bash`, change the hostname in there, and a second terminal still sees the old one. Same machine, same kernel, same gethostname() call, two different answers. We will go deep on how that magic works.
The article will be published tomorrow.
Want these articles directly in your inbox? Subscribe to the newsletter: internals-for-interns.com/newsletter/
#Linux #Containers #Namespaces
You can run `sudo unshare --uts bash`, change the hostname in there, and a second terminal still sees the old one. Same machine, same kernel, same gethostname() call, two different answers. We will go deep on how that magic works.
The article will be published tomorrow.
Want these articles directly in your inbox? Subscribe to the newsletter: internals-for-interns.com/newsletter/
#Linux #Containers #Namespaces
0
2
53
1,904
I want to share something that the @VictoriaMetrics team faced recently that I think it is an interesting case. I'm communicating it, but the heavy lifting of this was done by other members of the team.
The Go race detector found a race condition within the http client that catch us by surprise, so the team dig into it, and found two interesting things. If found this race in two places, one of the races, in our case, was not a problem, it could be, but not in our case, so we didn't fixed, but the second one actually was a bug, so we fixed it. If you want to know the details and understand what was happening, why not fixing it was the right choice for us, and why fixing the second one was needed, check out the blog post.
victoriametrics.com/blog/http-race…
The Go race detector found a race condition within the http client that catch us by surprise, so the team dig into it, and found two interesting things. If found this race in two places, one of the races, in our case, was not a problem, it could be, but not in our case, so we didn't fixed, but the second one actually was a bug, so we fixed it. If you want to know the details and understand what was happening, why not fixing it was the right choice for us, and why fixing the second one was needed, check out the blog post.
victoriametrics.com/blog/http-race…
2
9
81
9,989
Please welcome to my blog Kemal Akkoyun, who works at Datadog and helps maintain otelc, OpenTelemetry's compile-time instrumentation tool for Go. Today he shows how to take part in a Go build without patching the compiler.
The way in is `go build -toolexec`. Every compile, asm and link run goes through a program you pick, which gets the tool's path and arguments. From there, Kemal builds up step by step, first watching, then rewriting, and going down all the rabbit hole until he end up explaining how otelc does it.
Read it here: internals-for-interns.com/posts/hooking-…
#Golang #OpenTelemetry
The way in is `go build -toolexec`. Every compile, asm and link run goes through a program you pick, which gets the tool's path and arguments. From there, Kemal builds up step by step, first watching, then rewriting, and going down all the rabbit hole until he end up explaining how otelc does it.
Read it here: internals-for-interns.com/posts/hooking-…
#Golang #OpenTelemetry
1
7
84
8,103
At the #o11ysummit listening to my colleague @dianavtodea talking about carbon footprint as a standard signal for opentelemetry. A good reminder that performance can have more impact than you expect.
0
1
7
338
One of my favorite things about hosting guest posts: I get to read them before anybody else. Zero shame, full privileges. 😎
Monday's article is a guest post by @kakkoyun_me , engineer at @datadoghq, and maintainer of OpenTelemetry's otelc. He is comming to teach us about a Go flag most people never touch: go build -toolexec.
Here's the idea. go build doesn't compile your program in one go. It runs a graph of small steps: one compiler run per package, assembler runs, and a final linker run (many tool runs for a tiny program). With -toolexec, the go command runs each of those steps through a program you pick, handing it the tool's path and arguments. Sounds simple and small, and it is, but it brings you incredible power.
With this simple concept you can build powerful improvements: time each step, rewrite source files before the compiler sees them, or make the standard library call into your own code. That's exactly how tools like garble and otelc work, and Kemal drives us to the process step by step.
Article drops Monday!
Want these articles directly in your inbox? Subscribe to the newsletter: internals-for-interns.com/newsletter/
Monday's article is a guest post by @kakkoyun_me , engineer at @datadoghq, and maintainer of OpenTelemetry's otelc. He is comming to teach us about a Go flag most people never touch: go build -toolexec.
Here's the idea. go build doesn't compile your program in one go. It runs a graph of small steps: one compiler run per package, assembler runs, and a final linker run (many tool runs for a tiny program). With -toolexec, the go command runs each of those steps through a program you pick, handing it the tool's path and arguments. Sounds simple and small, and it is, but it brings you incredible power.
With this simple concept you can build powerful improvements: time each step, rewrite source files before the compiler sees them, or make the standard library call into your own code. That's exactly how tools like garble and otelc work, and Kemal drives us to the process step by step.
Article drops Monday!
Want these articles directly in your inbox? Subscribe to the newsletter: internals-for-interns.com/newsletter/
0
4
37
1,498
Next week, I’ll be at #O11ySummit in Prague on Monday, then @PromConIO in Munich on Wednesday and Thursday with the @VictoriaMetrics team.
If you’re there and want to chat about observability, performance, or Go, stop by the VictoriaMetrics booth and say hi! 🙂
If you’re there and want to chat about observability, performance, or Go, stop by the VictoriaMetrics booth and say hi! 🙂
1
1
10
672
Jesús Espino retweeted
Calling all my lovely #gophers! Will you be in Bologna for @golab_conf next month? Do your tastes stretch to privacy & secure data handling in #golang? Come join Auntie Ellie for a half day of brain bending #crypto #architecture #code golab.io/talks/knowing-…
0
8
9
578
Two weeks ago I went to @Percona Live Amsterdam, and I had an amazing experience. I love how every body was very Open Source minded and the topics of the events.
I also had the opportunity to talk about how we ingest and store petabytes of logs in VictoriaLogs.
If you find that interesting, you can check the recording here: youtube.com/watch?v=uc5kMV…, and check other recordings, there is a lot of good stuff.
I also had the opportunity to talk about how we ingest and store petabytes of logs in VictoriaLogs.
If you find that interesting, you can check the recording here: youtube.com/watch?v=uc5kMV…, and check other recordings, there is a lot of good stuff.
0
1
11
665
I'm scheduling the rest of this year for my blog. Here's what's coming to Internals for Interns from October to December.
🎤 Special guests, first Monday of each month:
- Oct 5: @kakkoyun_me, "Hooking into the Go Toolchain"
- Nov 2: @ainsleydev, "How //go:embed Works: From - Dec 7: @andydotxyz, "What Goes on behind a GUI"
I feel very luck to have this three outstanding engineers sharing what they know in my blog.
As it can't be in other way, I'll keep exploring Go. Now I'm switching from my previous focus on runtime or compiler to something more general. I'll be exploring SIMD, PGO, json/v2, and the tools that read and rewrite your code: analyzers, go vet and go fix.
I'm going to pick a spot for talking about filesystems again, but this time about NFS which is something that I wanted to explore for some time, and it is very different to other filesystems.
I'll be also wrapping up the Linux kernel series with three big ones:
- Namespaces: what a process can see (its own PIDs, mounts, network)
- Cgroups: how much a process can use (CPU, memory, I/O)
- eBPF: running small, verified programs inside the kernel
Put namespaces and cgroups together and you have the core of a container. That's exactly where I'm going next: on December 21 I start a new series, Understanding Containers.
If you want these articles directly in your inbox? Subscribe to the newsletter: internals-for-interns.com/newsletter/
🎤 Special guests, first Monday of each month:
- Oct 5: @kakkoyun_me, "Hooking into the Go Toolchain"
- Nov 2: @ainsleydev, "How //go:embed Works: From - Dec 7: @andydotxyz, "What Goes on behind a GUI"
I feel very luck to have this three outstanding engineers sharing what they know in my blog.
As it can't be in other way, I'll keep exploring Go. Now I'm switching from my previous focus on runtime or compiler to something more general. I'll be exploring SIMD, PGO, json/v2, and the tools that read and rewrite your code: analyzers, go vet and go fix.
I'm going to pick a spot for talking about filesystems again, but this time about NFS which is something that I wanted to explore for some time, and it is very different to other filesystems.
I'll be also wrapping up the Linux kernel series with three big ones:
- Namespaces: what a process can see (its own PIDs, mounts, network)
- Cgroups: how much a process can use (CPU, memory, I/O)
- eBPF: running small, verified programs inside the kernel
Put namespaces and cgroups together and you have the core of a container. That's exactly where I'm going next: on December 21 I start a new series, Understanding Containers.
If you want these articles directly in your inbox? Subscribe to the newsletter: internals-for-interns.com/newsletter/
0
0
22
1,046