> Ah, yet another valgrind false positive. If the memory was allocated
> with mmap() (which is different from IS_MMAPPED(), because the latter
> means that ONLY the chunk is in that map), then the first write access
> will cause a page fault. Avoiding write access therefore improves
> performance. A lot. Such a mapping will be read as zero without
> consequence.

My understanding is that doing a read followed by a possible write is slower than always doing a write for the reason that upon doing a read the process will halt
until the memory is brought into the CPU's cache which isn't a problem when just doing a write. I've just thrown together a simple application to test this (testing on a modern PC running alpine linux 64-bit in a virtualbox VM with 512MB RAM and 1 CPU core) with a normal musl library and a modified one whereby I've removed the 'if' check:

#include <time.h>
#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>

void TimedFunc()
{
    uint32_t loops = 64;
    uint32_t *ptr;
    while (loops > 0)
    {
        ptr = calloc(64, 2);
        free(ptr);
        --loops;
    }
}

void main()
{
    clock_t stime, etime;
    stime = clock();

    uint32_t runs = 0;
    while (runs < 16384)
    {
        TimedFunc();
        ++runs;
    }

    etime = clock();
    printf("%d loops in %d ms\r\n", runs, ((etime - stime) * 1000 / CLOCKS_PER_SEC));
}


Results are 74-148ms for the normal library and 70-72ms when the if statement is removed (about twice as fast). I've also got am original raspberry pi with a single CPU and have alpine linux on that so I've performed the same test using 32 loops, calloc(32, 2) and 8192 loops instead and see a similar result although it's much closer 411-412ms for the normal library and 405-408ms when the if statement is removed.
Surely a page fault will occur when attempting to read memory not writing it, it doesn't need to bring the page into the cache if no read is taking place therefore a page fault will not occur?