Re: 'disposable' dirty pages [was: Out Of Memory in v. 2.1]

Kenneth Albanowski (kjahds@kjahds.com)
Thu, 8 Oct 1998 10:50:14 -0400 (EDT)


On Thu, 8 Oct 1998, Jamie Lokier wrote:

> On Wed, Oct 07, 1998 at 12:03:48PM +0200, MOLNAR Ingo wrote:
> > if it's the libc malloc cache itself, then there need to be no action,
> > other than to remove that given area from the malloc cache. Due to the
> > asynchron behavior, more complex uses might be tricky.
>
> This should be possible without a fault handler and minimal libc support.
>
> When free() creates a large enough contiguous free region to be worth a
> syscall, call mmap(..., MAP_ANON | MAP_PRIVATE | MAP_DISCARDABLE, ...)
> to make an "optional zero-map" of the region.
>
> This doesn't modify the VMA, but simply marks the pages as discardable
> until they're next touched or written. The kernel then has the option
> of unmapping the pages at any time until they're next written/touched
> (individually), and as it's a zero-map VMA, that effectively sets the
> discarded pages to all zeros according to kernel demands.

Elegant. I proposed something related to the libc list a while ago
(calling mmap(/dev/zero) on large-enough released chunks of memory), but
this has the benefit of not making the VMA list grow for each release.

However, it does mean that the memory is not automatically available to
the system, at least not without a reclamation cycle. Consider a program
which allocates 20meg on start, and then lives with 64k of RAM forever
afterwards. That memory will never be released until the system actively
goes looking, due to low-memory conditions. I don't think it would make
sense to count the DISCARDABLE pages as actual free memory, as it isn't
available as such. Maybe another column in the memory report?

If this were implemented (and, assuming a flag bit for DISCARDABLE bit is
available, it seems to be worthwhile without any significant costs), then
I'd also suggest a "harvester daemon" that goes searching for discardable
pages, and reclaims then for the OS. Here (and with the low-memory
reclamation, come to think of it) some concern needs to be taken for the
VMA lists. Reclaiming a contiguous chunk of pages is more efficient then
individual.

> The process doesn't care whether any of those pages are discarded or
> not.

Which isn't quite true, unfortunately. To make this true, the act of
making the page DISCARDABLE should also zero it. Otherwise, you can tell
whether a page was discarded by whether it contains data, which in turn
means programs with bugs behaving differently depending on whether their
pages were discarded. A minor problem, but these pages would not be
transparent. (Free could of course zero the pages itself, and everyone
using mmap directly merely needs to be aware of the issue.)

-- 
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/