Bernd Schmidt <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
