Rayhaan JaufeerallyandClaude Fable 5.1
03f4f58ecb
A row's routes are in a vector that grew by one route at a time, so with four peers sending full tables every row's vector was reallocated three times as their routes arrived, and the reallocations were 7% of the daemon's CPU time in a profile of a four-peer load. This change has the first growth of a row take it to as many routes as the table has peers, at most 8 (`FIRST_ROOM`), since a prefix that one full table has, the others nearly always have too; after that it grows by a quarter as before. A table with one peer never grows a row and is unchanged. A route server's clients do not all announce every prefix, hence the cap: a row of a prefix that fewer peers announce has at most seven spare slots of 16 bytes. Measured in the Linux VM with four peers sending the synthetic table of 1.23 million prefixes: the kernel is in step 1.9 s after the first route instead of 2.2 s, the daemon's CPU time over the load is 5% lower, and it is 604 MiB resident instead of about 630, since there are no reallocation leftovers. With one peer nothing changes. Memory per route in the benchmarks, allocations counted: 77 bytes before and after with the synthetic table from four peers; 64 before and 65 after with the RIPE RIS dump's eight largest peers, whose load went from 2.8 s to 1.8 s on one thread, the allocation counting making every reallocation dearer than it is in the daemon. Also tried and not adopted, with the new `JEMALLOC_CONF` setting of the profiling script: transparent huge pages for the allocator (`thp:always,metadata_thp:always`). Over three pairs of runs with one peer the table arrived in 0.66, 1.17 and 0.70 s with them against 0.87, 0.75 and 0.87 s without, the CPU time was within the noise, and the daemon was 60 to 100 MiB larger. An arena for the routes would not help either: jemalloc's size classes already give rows exact 16, 32, 48 and 64 byte allocations, and the cost was the number of reallocations, not the allocator. Testing: the table tests, including the one that grows a row past 65,535 routes, pass; the kernel tests and the interoperability lab pass. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Documentation sources
This directory holds the sources of the Ferrix documentation site, built with Zola:
zola --root docs serve # http://127.0.0.1:1111, rebuilt on every change
zola --root docs build # into docs/public
The pages under content/ are Markdown with Zola additions, which a code
forge does not render:
- The block between
+++lines at the top of each page is its front matter: the title, description and position in the navigation. {{ example(name="...") }}and{{ file(name="...") }}insert a file fromexamples/, whole, at that point. Open the file to read it.- Links of the form
@/docs/...are internal links that Zola resolves and checks at build time. On the forge they do not work; the target is the path after@/, undercontent/.
To read the documentation as intended, build the site, or read it where
it is published (base_url in config.toml).
STYLE.md is the writing guide. CI builds the site on every push and fails
on a link to a page or an anchor that does not exist; zola --root docs check also checks external links.