Re: avoiding dirty code pages with fixups

[Jamie Lokier <jamie@shareable.org>]

Andy Isaacson wrote:
> This is sorta like MAP_PRIVATE, but instead of writing the dirty
> page out to the swapfile, I want the page never to leave RAM.  If
> the kernel decides to evict the page, it should just drop it and
> invalidate the virtual address range.  When my program faults it
> back in, provide me with the contents of the page *as they exist in
> the backing file*.

That idea has come up about a thousand million times.  Well, three.
It's a good one :)

It has lots of uses, not just the one you describe.  For example,
cacheing generated image data.

It would also be nice for a memory allocator to be able to convert a
region from MAP_PRIVATE to MAP_SCRATCH and back, so that freed blocks
of memory can be reclaimed by the system but only when there is memory
pressure.

> The downside is the additional computation on page-in.

> It is a function of how many fixups there are per page, and of how
> much work ld.so does to satisfy a fixup.  I don't have a good feel
> for how expensive ld.so's fixup mechanism is... any comments?

The other downside of your idea is that every instance of a program
has more dirty pages.  While it is true that the pages do not require
disk I/O, they still take up RAM that could be used for other page
cache things.

-- Jamie