Re: avoiding dirty code pages with fixups

[Jamie Lokier]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/