On Sat 11-09-21 10:40:08, Vasily Averin wrote: > 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. Is there any upper bound or is it just bounded by the number of tasks/threads (that can be controlled by pid controller at least)? > 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. Is there any measurable performance impact in this particular case? > In addition, any usual task consumes much more accounted memory, > so 2 pages of this temporal buffer can be safely ignored. > > Link: https://patchwork.kernel.org/project/linux-fsdevel/patch/20171005222144.123797-1-shakeelb@xxxxxxxxxx/ > > Fixes: 18319498fdd4 ("memcg: enable accounting of ipc resources") > Signed-off-by: Vasily Averin <vvs@xxxxxxxxxxxxx> > --- > ipc/sem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/ipc/sem.c b/ipc/sem.c > index f833238df1ce..6693daf4fe11 100644 > --- a/ipc/sem.c > +++ b/ipc/sem.c > @@ -2238,7 +2238,7 @@ static long do_semtimedop(int semid, struct sembuf __user *tsops, > return -EINVAL; > > 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 -- Michal Hocko SUSE Labs
