Could you be more explicit about _why_ we need to remove this tunable?
I am not saying I disagree, the removal simplifies the code but I do not
really see any justification here.
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.
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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Michal Hocko <mhocko@kernel.org> Date: 2017-11-27 18:32:18
On Mon 27-11-17 09:25:16, Andi Kleen wrote:
Michal Hocko [off-list ref] writes:
quoted
Could you be more explicit about _why_ we need to remove this tunable?
I am not saying I disagree, the removal simplifies the code but I do not
really see any justification here.
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.
Why cannot you increase the limit?
The reason the limit was there originally because it allows a DoS
attack against the kernel by filling all unswappable memory up with VMAs.
We can reduce the effect by accounting vmas to memory cgroups.
--
Michal Hocko
SUSE Labs
From: Mikael Pettersson <mikpelinux@gmail.com> Date: 2017-11-27 19:36:55
On Mon, Nov 27, 2017 at 6:25 PM, Andi Kleen [off-list ref] 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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Michal Hocko <mhocko@kernel.org> Date: 2017-11-27 19:57:32
On Mon 27-11-17 19:32:18, Michal Hocko wrote:
On Mon 27-11-17 09:25:16, Andi Kleen wrote:
[...]
quoted
The reason the limit was there originally because it allows a DoS
attack against the kernel by filling all unswappable memory up with VMAs.
We can reduce the effect by accounting vmas to memory cgroups.
As it turned out we already do.
vm_area_cachep = KMEM_CACHE(vm_area_struct, SLAB_PANIC|SLAB_ACCOUNT);
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Michal Hocko <mhocko@kernel.org> Date: 2017-11-27 20:52:10
On Mon 27-11-17 12:21:21, Andi Kleen wrote:
On Mon, Nov 27, 2017 at 08:57:32PM +0100, Michal Hocko wrote:
quoted
On Mon 27-11-17 19:32:18, Michal Hocko wrote:
quoted
On Mon 27-11-17 09:25:16, Andi Kleen wrote:
[...]
quoted
quoted
The reason the limit was there originally because it allows a DoS
attack against the kernel by filling all unswappable memory up with VMAs.
We can reduce the effect by accounting vmas to memory cgroups.
As it turned out we already do.
vm_area_cachep = KMEM_CACHE(vm_area_struct, SLAB_PANIC|SLAB_ACCOUNT);
That only helps if you have memory cgroups enabled. It would be a regression
to break the accounting on all the systems that don't.
I agree. And I didn't say we should remove the existing limit. I am just
saying that we can reduce existing problems by increasing the limit and
relying on memcg accounting where possible.
--
Michal Hocko
SUSE Labs