ripatel-jump, a censoring Fachidiot...

[ghost]

...with no idea how to cooperate and accept higher grade contributions.

Sloppy documentation and processes, a shame for decentralization.

[ripatel-fd]

@abebeos I've transferred this to the support section, since this is technically not an issue with the Firedancer code that can be addressed immediately. It's rather a mix of

• The code base not supporting your system
• Lack of clarity whether we want to support environments other than Linux on bare metal
• Lack of documentation which environments we are currently supporting

Anyways, the unit test you are trying to run is defaulting to 1 gigantic page for memory (see the error message --wksp not specified, using an anonymous local workspace, --page-sz gigantic, --page-cnt 1).

Huge/gigantic pages are a hardware feature of the x86 MMU and require system setup before running: https://wiki.debian.org/Hugepages

You have a few options here:

• Instead of using make unit-test, manually run the test and set --page-sz normal --page-cnt 262144 (aka memory backed by 262144 "normal" 4K pages)
• Follow the README instructions for reserving gigantic pages, e.g.

  sudo build/linux/gcc/x86_64/bin/fd_shmem_cfg \
    alloc 8 gigantic 0                         \
    alloc 512 huge 0
   sudo build/linux/gcc/x86_64/bin/fd_shmem_cfg init 0700 $USER ""

  Meaning: 8x 1GiB "gigantic" pages and 512x 2MiB "huge" pages

Another complication here is the use of virtualization (Hyper-V). More likely than not, Hyper-V will not support allocation of gigantic pages.

The problem is another symptom of Firedancer being in early development. The run-unit-test target is just a quick hack for now that depends on gigantic pages being available on the system (which, of course, is undocumented 😓) For now, I would recommend using a Linux installation on "bare metal", i.e. without any virtualization.

A couple of dev UX things will need to mature on our side:

• Document the minimum system requirements for development
• Lower these requirements (e.g. support "less capable" environments such as Docker for Windows, GitHub codespaces. etc)
• For unit tests, automatically choose the best available source of memory (e.g. request normal pages via sbrk or mmap if gigantic pages are not available)

[ripatel-fd]

@abebeos The documentation problems are indeed easy to fix. I will work on those soon. Thank you for the feedback.