Linus proposes to revert an accounting for sops objects in do_semtimedop() because it's really just a temporary buffer for a single semtimedop() system call.
This object can consume up to 2 pages, syscall is sleeping one, size and duration can be controlled by user, and this allocation can be repeated by many thread at the same time. However Shakeel Butt pointed that there are much more popular objects with the same life time and similar memory consumption, the accounting of which was decided to be rejected for performance reasons. Considering at least 2 pages for task_struct and 2 pages for the kernel stack, a back of the envelope calculation gives a footprint amplification of <1.5 so this temporal buffer can be safely ignored. The factor would IMO be interesting if it was >> 2 (from the PoV of excessive (ab)use, fine-grained accounting seems to be currently unfeasible due to performance impact). Link: https://lore.kernel.org/lkml/90e254df-0dfe-f080-011e-b7c53ee7f...@virtuozzo.com/ Fixes: 18319498fdd4 ("memcg: enable accounting of ipc resources") Signed-off-by: Vasily Averin <v...@virtuozzo.com> Acked-by: Michal Hocko <mho...@suse.com> Reviewed-by: Michal Koutný <mkou...@suse.com> Acked-by: Shakeel Butt <shake...@google.com> Signed-off-by: Linus Torvalds <torva...@linux-foundation.org> (cherry picked from commit 6a4746ba06191e23d30230738e94334b26590a8a) https://jira.sw.ru/browse/PSBM-133990 Signed-off-by: Vasily Averin <v...@virtuozzo.com> --- ipc/sem.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/ipc/sem.c b/ipc/sem.c index 1a8b9f0ac047..4c4fdf010793 100644 --- a/ipc/sem.c +++ b/ipc/sem.c @@ -2005,8 +2005,7 @@ static long do_semtimedop(int semid, struct sembuf __user *tsops, if (nsops > ns->sc_semopm) return -E2BIG; if (nsops > SEMOPM_FAST) { - sops = kvmalloc_array(nsops, sizeof(*sops), - GFP_KERNEL_ACCOUNT); + sops = kvmalloc_array(nsops, sizeof(*sops), GFP_KERNEL); if (sops == NULL) return -ENOMEM; } -- 2.25.1 _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel