On Mon, Nov 27, 2017 at 6:25 PM, Andi Kleen <ak@xxxxxxxxxxxxxxx> wrote: > It's an arbitrary scaling limit on the how many mappings the process > has. The more memory you have the bigger a problem it is. We've > ran into this problem too on larger systems. > > The reason the limit was there originally because it allows a DoS > attack against the kernel by filling all unswappable memory up with VMAs. > > The old limit was designed for much smaller systems than we have > today. > > There needs to be some limit, but it should be on the number of memory > pinned by the VMAs, and needs to scale with the available memory, > so that large systems are not penalized. Fully agreed. One problem with the current limit is that number of VMAs is only weakly related to the amount of memory one has mapped, and is also prone to grow due to memory fragmentation. I've seen processes differ by 3X number of VMAs, even though they ran the same code and had similar memory sizes; they only differed on how long they had been running and which servers they ran on (and how long those had been up). > Unfortunately just making it part of the existing mlock limit could > break some existing setups which max out the mlock limit with something > else. Maybe we need a new rlimit for this? > > -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
