<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Mmap on Taras&#39; Blog on AI, Perf, Hacks</title>
    <link>/tags/mmap/</link>
    <description>Recent content in Mmap on Taras&#39; Blog on AI, Perf, Hacks</description>
    <image>
      <title>Taras&#39; Blog on AI, Perf, Hacks</title>
      <url>/images/papermod-cover.png</url>
      <link>/images/papermod-cover.png</link>
    </image>
    <generator>Hugo -- 0.147.0</generator>
    <language>en</language>
    <copyright>Taras Glek</copyright>
    <lastBuildDate>Tue, 15 Mar 2022 13:26:36 +0100</lastBuildDate>
    <atom:link href="/tags/mmap/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>mmap Page Fault Tracing with bpftrace and ext4</title>
      <link>/posts/mmap-page-fault-tracing-via-ext4/</link>
      <pubDate>Tue, 15 Mar 2022 13:26:36 +0100</pubDate>
      <guid>/posts/mmap-page-fault-tracing-via-ext4/</guid>
      <description>&lt;p&gt;Previous blog post on how to &lt;a href=&#34;../ebpf-mmap-page-fault-tracing/&#34;&gt;trace Firefox IO using bpftrace&lt;/a&gt; via official page_fault_user tracepoint left me a bit unsatisfied with how complicated it turned out. Complexity has potential to be error-prone and the syscall-tracing dependency makes it impossible to trace IO within the main executable.&lt;/p&gt;
&lt;p&gt;I decided to try reimplement the trace using my old approach of tracing ext4 functions that handle page-faults. This turned out to be much more robust. This is now documented on my &lt;a href=&#34;https://github.com/tarasglek/bpftrace_pagefaults/tree/main/ext4&#34;&gt;github&lt;/a&gt;. It&amp;rsquo;s ugly in that it&amp;rsquo;s dependent on internal kernel structures, but it catches 100% of the IO and requires no post-trace syscall-correlation/fudging.&lt;/p&gt;</description>
    </item>
    <item>
      <title>EBPF for Tracing How Firefox Uses Page Faults to Load Libraries</title>
      <link>/posts/ebpf-mmap-page-fault-tracing/</link>
      <pubDate>Tue, 22 Feb 2022 12:29:10 +0200</pubDate>
      <guid>/posts/ebpf-mmap-page-fault-tracing/</guid>
      <description>&lt;p&gt;Modern browsers are some of the most complicated programs ever written. For example, the main Firefox library on my system is over 130Mbytes. Doing 130MB of IO poorly can be quite a performance hit, even with SSDs! :).&lt;/p&gt;
&lt;p&gt;Few people seem to understand how memory-mapped IO works. There are no pre-canned tools to observe it on Linux, thus even even fewer know how to observe it. Years ago, when I was working on Firefox startup performance, I discovered that libraries were loaded backwards (&lt;a href=&#34;https://htmlpreview.github.io/?https://github.com/tarasglek/taras.glek.net.old/blob/jekyll/blog/2010/03/24/linux-why-loading-binaries-from-disk-sucks/index.html&#34;&gt;blog1&lt;/a&gt;, &lt;a href=&#34;https://htmlpreview.github.io/?https://github.com/tarasglek/taras.glek.net.old/blob/jekyll/blog/2010/05/27/startup-backward-constructors/index.html&#34;&gt;blog2&lt;/a&gt;, &lt;a href=&#34;https://arxiv.org/pdf/1010.2196.pdf&#34;&gt;paper&lt;/a&gt;, GCC &lt;a href=&#34;https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770&#34;&gt;bug&lt;/a&gt;) on Linux. Figuring this out was super-painful, involved learning SystemTap and a setting up a just-right kernel with headers and symbols.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
