Behavior of madvise(MADV_FREE)

Poul-Henning Kamp phk at phk.freebsd.dk
Fri Oct 12 17:13:53 UTC 2012


--------
In message <9FEBC10C-C453-41BE-8829-34E830585E90 at xcllnt.net>, Marcel Moolenaar writes:

>Now on to the questions:
>1.  madvise(MADV_FREE) marks the pages as clean and moves
>    them to the inactive queue. 

You can blame me for MADV_FREE, I nagged dyson into adding it for
phkmalloc back when 16meg RAM cost a fortune.

The main point of MADV_FREE when was to prevent a page-out of a
dirty page, when the actual bits in the page were discarded from
the applications point of view.

The idea was for it to be a very fast operation, which would
(potentially) save two disk operations, and the implementation
simply washed the dirty bits away.

(I think a later modification added further VM-wizardry to retain
the allocated paging area, while avoiding the page-in in the case
the pages were stolen.)

The mapping were left alone, because it was estimated and measured
that there were a high frequency of mapping reuse, in particular
in the WorldStone where multiple passes of GCC competed for physical
memory.  The reference bit were left alone to not disturb the
perceived/ measured VM-footprint of the process.

I seem to recall that we experimented with a more aggressive
version which severed the mapping and sent the page to pre-zeroing
but the benchmarks showed too much overhead in the common case
and too little gain in the relevant scenario.

The name was clearly a mistake, but MADV_CLEAN would have been
worse, and none of us had any other ideas at the time.  Today I
would have called it MADV_GARBAGE or MADV_RECYCLE.

Given that paging anonymous pages to disk is not a major activity
and unlikely to ever become a performance bottleneck again, it may
make good sense to let MADV_FREE make the pages more appetizing
for the rest of the system.

But all things considered, I would advocate implementing MADV_RECYCLE
for that, we need more nuance and expressability in madvice(2) and
MADV_RECYCLE would be a good addition in its own right.

Poul-Henning


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


More information about the freebsd-arch mailing list