<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Linux on Manuel Bernhardt</title><link>https://manuel.bernhardt.io/tags/linux/</link><description>Recent content in Linux on Manuel Bernhardt</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 16 Nov 2023 19:49:04 +0100</lastBuildDate><atom:link href="https://manuel.bernhardt.io/tags/linux/index.xml" rel="self" type="application/rss+xml"/><item><title>On pinning and isolating CPU cores</title><link>https://manuel.bernhardt.io/posts/2023-11-16-core-pinning/</link><pubDate>Thu, 16 Nov 2023 17:27:11 +0100</pubDate><guid>https://manuel.bernhardt.io/posts/2023-11-16-core-pinning/</guid><description>&lt;p>This year I have been involved in running performance benchmarks of &lt;a href="https://aeron.io">Aeron&lt;/a> over at &lt;a href="https://weareadaptive.com">Adaptive&lt;/a> on two major cloud providers. I learned quite a few things about the &lt;del>arcane arts&lt;/del> &lt;del>science&lt;/del> craft of running performance benchmarks.&lt;/p>
&lt;p>When benchmarking a piece of software, you really want to get the best performance out of it, which is to say that you also want to run it under the best conditions in order to see what is possible. One aspect I&amp;rsquo;d like to cover in this article is related to giving the program exclusive access to the CPU core(s) it needs to run, without having other threads interfering with the execution. This involves:&lt;/p></description></item></channel></rss>