<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
    <title>Sergey&#x27;s Blog</title>
    <link rel="self" type="application/atom+xml" href="https://polovko.me/atom.xml"/>
    <link rel="alternate" type="text/html" href="https://polovko.me"/>
    <generator uri="https://www.getzola.org/">Zola</generator>
    <updated>2026-07-11T00:00:00+00:00</updated>
    <id>https://polovko.me/atom.xml</id>
    <entry xml:lang="en">
        <title>Introducing Meerkat: an experiment in global consensus</title>
        <published>2026-07-11T00:00:00+00:00</published>
        <updated>2026-07-11T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Sergey Polovko
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://polovko.me/pins/introducing-meerkat-an-experiment-in-global-consensus/"/>
        <id>https://polovko.me/pins/introducing-meerkat-an-experiment-in-global-consensus/</id>
        
        <content type="html" xml:base="https://polovko.me/pins/introducing-meerkat-an-experiment-in-global-consensus/">&lt;p&gt;Cloudflare Research&#x27;s writeup on Meerkat, an experimental consensus service that keeps control-plane state strongly consistent across their 330+ data centers. The interesting part is that it drops the leader entirely: instead of Raft-style leader election through timeouts, which the post argues are hard to tune on the wide-area internet and have caused availability incidents, Meerkat builds on the QuePaxa algorithm where any replica can accept writes at any time and concurrent proposals interfere constructively rather than fighting. It maintains a linearizable log split into slots, and this is the first industrial deployment of QuePaxa at global scale. Worth reading if you care about how consensus actually behaves across unpredictable wide-area links rather than in a single datacenter.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>How &#x2F;dev&#x2F;null and Friends Work Inside the Linux Kernel</title>
        <published>2026-03-08T00:00:00+00:00</published>
        <updated>2026-03-08T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Sergey Polovko
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://polovko.me/blog/how-dev-null-works-linux-kernel/"/>
        <id>https://polovko.me/blog/how-dev-null-works-linux-kernel/</id>
        
        <summary type="html">&lt;p&gt;If you list all device files with major number 1 on a Linux machine, you&#x27;ll see something like this:&lt;&#x2F;p&gt;
&lt;pre class=&quot;giallo&quot; style=&quot;color: #24292E; background-color: #FFFFFF;&quot;&gt;&lt;code data-lang=&quot;plain&quot;&gt;&lt;span class=&quot;giallo-l&quot;&gt;&lt;span&gt;$ ls -la &#x2F;dev&#x2F; | grep &amp;#39; 1, &amp;#39;&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span&gt;crw-rw-rw-  1 root root      1,     7 Jan 18 20:01 full&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span&gt;crw-r--r--  1 root root      1,    11 Jan 18 20:01 kmsg&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span&gt;crw-r-----  1 root kmem      1,     1 Jan 18 20:01 mem&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span&gt;crw-rw-rw-  1 root root      1,     3 Jan 18 20:01 null&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span&gt;crw-r-----  1 root kmem      1,     4 Jan 18 20:01 port&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span&gt;crw-rw-rw-  1 root root      1,     8 Jan 18 20:01 random&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span&gt;crw-rw-rw-  1 root root      1,     9 Jan 18 20:01 urandom&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;
&lt;span class=&quot;giallo-l&quot;&gt;&lt;span&gt;crw-rw-rw-  1 root root      1,     5 Jan 18 20:01 zero&lt;&#x2F;span&gt;&lt;&#x2F;span&gt;&lt;&#x2F;code&gt;&lt;&#x2F;pre&gt;
&lt;p&gt;Every Linux system has them. You&#x27;ve used &lt;code&gt;&#x2F;dev&#x2F;null&lt;&#x2F;code&gt; a thousand times. You&#x27;ve probably read from &lt;code&gt;&#x2F;dev&#x2F;urandom&lt;&#x2F;code&gt; or &lt;code&gt;&#x2F;dev&#x2F;random&lt;&#x2F;code&gt;. But have you ever looked at what &lt;em&gt;backs&lt;&#x2F;em&gt; these files inside the kernel?&lt;&#x2F;p&gt;
&lt;p&gt;What makes these eight devices special is that they are among the simplest real drivers in Linux. There&#x27;s no hardware to initialize, no DMA buffers to manage, no firmware to load. Just pure logic: &quot;when userspace calls &lt;code&gt;read()&lt;&#x2F;code&gt;, do &lt;em&gt;this&lt;&#x2F;em&gt;.&quot; That makes them the perfect starting point for understanding how &lt;em&gt;any&lt;&#x2F;em&gt; Linux character device driver works.&lt;&#x2F;p&gt;
&lt;p&gt;We&#x27;ll walk through their implementations line by line. Along the way, you&#x27;ll see the interface every character device must conform to, the patterns that the kernel uses to dispatch I&#x2F;O to the right handler, and the design choices that separate a minimal driver from a production-ready one. By the end, you&#x27;ll have a concrete blueprint for writing your own.&lt;&#x2F;p&gt;
&lt;p&gt;All the code in this post comes from &lt;strong&gt;Linux 6.19&lt;&#x2F;strong&gt; (&lt;a rel=&quot;external&quot; href=&quot;https:&#x2F;&#x2F;elixir.bootlin.com&#x2F;linux&#x2F;v6.19&#x2F;source&#x2F;drivers&#x2F;char&#x2F;mem.c&quot;&gt;&lt;code&gt;drivers&#x2F;char&#x2F;mem.c&lt;&#x2F;code&gt;&lt;&#x2F;a&gt; and &lt;a rel=&quot;external&quot; href=&quot;https:&#x2F;&#x2F;elixir.bootlin.com&#x2F;linux&#x2F;v6.19&#x2F;source&#x2F;drivers&#x2F;char&#x2F;random.c&quot;&gt;&lt;code&gt;drivers&#x2F;char&#x2F;random.c&lt;&#x2F;code&gt;&lt;&#x2F;a&gt;). Let&#x27;s start with &lt;code&gt;open(&quot;&#x2F;dev&#x2F;null&quot;, ...)&lt;&#x2F;code&gt; and trace it all the way down to the two-line C function that makes it work.&lt;&#x2F;p&gt;</summary>
        
    </entry>
    <entry xml:lang="en">
        <title>What Every Programmer Should Know About Memory</title>
        <published>2025-03-20T00:00:00+00:00</published>
        <updated>2025-03-20T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Sergey Polovko
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://polovko.me/pins/what-every-programmer-should-know-about-memory/"/>
        <id>https://polovko.me/pins/what-every-programmer-should-know-about-memory/</id>
        
        <content type="html" xml:base="https://polovko.me/pins/what-every-programmer-should-know-about-memory/">&lt;p&gt;Ulrich Drepper&#x27;s classic long-form guide to how modern memory hardware actually
works: CPU caches, cache coherency, virtual memory, NUMA, and the concrete
techniques you can use to write cache-friendly code. Dated in a few specifics but
still the single best foundation for reasoning about memory performance on
today&#x27;s machines.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>A Decade of Dynamo: Powering the next wave of high-performance apps</title>
        <published>2025-01-15T00:00:00+00:00</published>
        <updated>2025-01-15T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Sergey Polovko
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://polovko.me/pins/a-decade-of-dynamo/"/>
        <id>https://polovko.me/pins/a-decade-of-dynamo/</id>
        
        <content type="html" xml:base="https://polovko.me/pins/a-decade-of-dynamo/">&lt;p&gt;A retrospective USENIX ATC paper on how DynamoDB evolved from the original Dynamo
design into a fully managed service. It&#x27;s a rare, candid look at the operational
lessons behind a system running at enormous scale: predictable performance,
admission control, durability, and the trade-offs made to keep tail latencies
flat. Good reading if you care about how distributed storage behaves in
production rather than on paper.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>GCRA: a simple and elegant rate-limiting algorithm</title>
        <published>2024-09-01T00:00:00+00:00</published>
        <updated>2024-09-01T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Sergey Polovko
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://polovko.me/pins/gcra/"/>
        <id>https://polovko.me/pins/gcra/</id>
        
        <content type="html" xml:base="https://polovko.me/pins/gcra/">&lt;p&gt;A clear walkthrough of the Generic Cell Rate Algorithm (GCRA), the mechanism
behind the leaky-bucket rate limiter. Instead of tracking a counter that has to
be refilled on a timer, GCRA stores a single timestamp — the theoretical arrival
time of the next conforming request — and decides admission with a bit of
arithmetic. The post builds the intuition step by step and shows why this is both
memory-cheap and pleasant to implement.&lt;&#x2F;p&gt;
</content>
        
    </entry>
    <entry xml:lang="en">
        <title>Introduction to JIT Compilation</title>
        <published>2012-10-04T00:00:00+00:00</published>
        <updated>2012-10-04T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Sergey Polovko
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://polovko.me/blog/introduction-in-jit-compilation/"/>
        <id>https://polovko.me/blog/introduction-in-jit-compilation/</id>
        
        <summary type="html">&lt;p&gt;The Java HotSpot VM (which Oracle acquired after purchasing Sun Microsystems) forms the basis for both the Java Virtual Machine (JVM) and OpenJDK (an open-source project). Like all Java virtual machines, the Java HotSpot VM provides the necessary environment for executing bytecode. In practice, it is responsible for three main functions:&lt;&#x2F;p&gt;
&lt;ul&gt;
&lt;li&gt;bytecode interpretation&lt;&#x2F;li&gt;
&lt;li&gt;class loading and type checking&lt;&#x2F;li&gt;
&lt;li&gt;memory management&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
&lt;p&gt;This article focuses on bytecode interpretation, specifically the optimizations performed by the virtual machine.&amp;hellip;
&lt;&#x2F;p&gt;
</summary>
        
    </entry>
    <entry xml:lang="en">
        <title>About Sizes in Java</title>
        <published>2012-09-26T00:00:00+00:00</published>
        <updated>2012-09-26T00:00:00+00:00</updated>
        
        <author>
          <name>
            
              Sergey Polovko
            
          </name>
        </author>
        
        <link rel="alternate" type="text/html" href="https://polovko.me/blog/about-sizes-in-java/"/>
        <id>https://polovko.me/blog/about-sizes-in-java/</id>
        
        <summary type="html">&lt;p&gt;Recently, I&#x27;ve been pondering the question: &quot;How can one accurately assess the amount of memory allocated for objects in Java?&quot; There are several articles on Habrahabr &lt;a rel=&quot;external&quot; href=&quot;http:&#x2F;&#x2F;habrahabr.ru&#x2F;post&#x2F;134102&#x2F;&quot;&gt;[1]&lt;&#x2F;a&gt;, &lt;a rel=&quot;external&quot; href=&quot;http:&#x2F;&#x2F;habrahabr.ru&#x2F;post&#x2F;134910&#x2F;&quot;&gt;[2]&lt;&#x2F;a&gt; dedicated to this topic. However, I wasn&#x27;t quite satisfied with the approach used by the authors. Therefore, I decided to delve into the internals of the OpenJDK Hotspot VM (hereafter referred to as Hotspot) and try to understand how things really work.&lt;&#x2F;p&gt;
&lt;h2 id=&quot;data-types-in-java&quot;&gt;Data Types in Java&lt;&#x2F;h2&gt;
&lt;ul&gt;
&lt;li&gt;Primitives (byte, short, char, int, float, long, double, boolean).&lt;&#x2F;li&gt;
&lt;li&gt;Objects. The size of an object depends on the specific VM implementation and the processor architecture, so a definitive answer is not possible. Nonetheless, it&#x27;s interesting to explore (using a specific VM as an example) what size of memory is allocated for a Java object.&lt;&#x2F;li&gt;
&lt;li&gt;Arrays. One-dimensional linear structures that can contain all listed types (including other arrays). Arrays are also objects but with a specific structure.&amp;hellip;
&lt;&#x2F;li&gt;
&lt;&#x2F;ul&gt;
</summary>
        
    </entry>
</feed>
