On 05/21/2018 03:35 PM, Daniel Colascione wrote: >> I know folks use memfd to figure out >> how much memory pressure we are under. I guess that would trigger when >> you consume lots of memory with VMAs. > > I think you're thinking of the VM pressure level special files, not memfd, > which creates an anonymous tmpfs file. Yep, you're right. >> VMAs are probably the most similar to things like page tables that are >> kernel memory that can't be directly reclaimed, but do get freed at >> OOM-kill-time. But, VMAs are a bit harder than page tables because >> freeing a page worth of VMAs does not necessarily free an entire page. > > I don't understand. We can reclaim memory used by VMAs by killing the > process or processes attached to the address space that owns those VMAs. > The OOM killer should Just Work. Why do we have to have some special limit > of VMA count? The OOM killer doesn't take the VMA count into consideration as far as I remember. I can't think of any reason why not except for the internal fragmentation problem. The current VMA limit is ~12MB of VMAs per process, which is quite a bit. I think it would be reasonable to start considering that in OOM decisions, although it's surely inconsequential except on very small systems. There are also certainly denial-of-service concerns if you allow arbitrary numbers of VMAs. The rbtree, for instance, is O(log(n)), but I 'd be willing to be there are plenty of things that fall over if you let the ~65k limit get 10x or 100x larger.
