Re: [PATCH] NOMMU: Separate out VMAs

[David Howells]

Bernd Schmidt <bernds_cb1@xxxxxxxxxxx> wrote:

> In do_mmap_private, I've commented out the logic to free excess pages, as it
> fragments terribly

I wonder if there's a good heuristic for this.  The problem is that whilst
not releasing excess pages _may_ seem like a good idea, if your system is
something like a single persistent app, then it really is not.

For instance, if such an app allocates a byte over 16MB (perhaps implicitly in
the binfmt driver), then you'd completely waste a large chunk of RAM.  In the
16MB+1 case, the wastage would be a byte less than 16MB.

> and causes a simple
>  while true; do cat /proc/buddyinfo; done
> loop to go oom.

Are you sure it's not just another leak?

> Also, I think you're freeing high-order pages unaligned to
> their order?

Yeah, but some of the pages might still be in use when we want to release
them.

> In shrink_vma, we must save the mm across calls to remove_vma_from_mm (oops
> when telnetting into the box).

I'll have a look, but I don't see that.

> In do_munmap, we can deal with freeing more than one vma.  I've not touched
> the rb-tree logic in the shared file case, as I have no idea what it's trying
> to do given that only exact matches are allowed.

I'd generally rather not do this.  You can't use MAP_FIXED to request adjacent
regions, so why should you anticipate there would be any?

> It still does not survive my mmap stress-tester, so I'll keep looking.

Thanks.

> Why do we need vm_regions for anonymous memory?  Wouldn't it be enough to just
> have a VMA?

It makes it simpler to have a common way of allocating memory for both anon
regions and file regions.

David
-
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/