From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 69424C07E95 for ; Tue, 20 Jul 2021 16:46:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4A57C610A0 for ; Tue, 20 Jul 2021 16:46:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233549AbhGTQFZ (ORCPT ); Tue, 20 Jul 2021 12:05:25 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:46012 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231201AbhGTQCT (ORCPT ); Tue, 20 Jul 2021 12:02:19 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1m5spc-006lfH-Av; Tue, 20 Jul 2021 10:42:56 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95]:50550 helo=email.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1m5spb-004FeE-0Y; Tue, 20 Jul 2021 10:42:55 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Vasily Averin Cc: Andrew Morton , cgroups@vger.kernel.org, Michal Hocko , Shakeel Butt , Johannes Weiner , Vladimir Davydov , Roman Gushchin , Jens Axboe , Oleg Nesterov , linux-kernel@vger.kernel.org References: <87k0lmryyp.fsf@disp2133> <56816a9d-c2e5-127d-4d90-5d7d17782c8a@virtuozzo.com> Date: Tue, 20 Jul 2021 11:42:47 -0500 In-Reply-To: <56816a9d-c2e5-127d-4d90-5d7d17782c8a@virtuozzo.com> (Vasily Averin's message of "Tue, 20 Jul 2021 11:35:19 +0300") Message-ID: <87wnplos1k.fsf@disp2133> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1m5spb-004FeE-0Y;;;mid=<87wnplos1k.fsf@disp2133>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+JI59ywzeupllyPmyImzi2tt60wS/c3Cs= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v5 13/16] memcg: enable accounting for signals X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Vasily Averin writes: > On 7/19/21 8:32 PM, Eric W. Biederman wrote: >> Vasily Averin writes: >> >>> When a user send a signal to any another processes it forces the kernel >>> to allocate memory for 'struct sigqueue' objects. The number of signals >>> is limited by RLIMIT_SIGPENDING resource limit, but even the default >>> settings allow each user to consume up to several megabytes of memory. >>> Moreover, an untrusted admin inside container can increase the limit or >>> create new fake users and force them to sent signals. >> >> Not any more. Currently the number of sigqueue objects is limited >> by the rlimit of the creator of the user namespace of the container. >> >>> It makes sense to account for these allocations to restrict the host's >>> memory consumption from inside the memcg-limited container. >> >> Does it? Why? The given justification appears to have bit-rotted >> since -rc1. > > Could you please explain what was changed in rc1? > From my POV accounting is required to help OOM-killer to select proper target. You can no longer escape the rlimit of the creator of the user namespace, by creating multiple users inside of the user namespace. The users (in the user namespace) will have their individual rlimits but are jointly by the limit of the creator of the user namespace at the time the user namespace was created. >> I know a lot of these things only really need a limit just to catch a >> program that starts malfunctioning. If that is indeed the case >> reasonable per-resource limits are probably better than some great big >> group limit that can be exhausted with any single resource in the group. >> >> Is there a reason I am not aware of that where it makes sense to group >> all of the resources together and only count the number of bytes >> consumed? > > Any new limits: > a) should be set properly depending on huge number of incoming parameters. > b) should properly notify about hits > c) should be updated properly after b) > d) do a)-c) automatically if possible > > In past OpenVz had own accounting subsystem, user beancounters (UBC). > It accounted and limited 20+ resources per-container: numfiles, file locks, > signals, netfilter rules, socket buffers and so on. > I assume you want to do something similar, so let me share our experience. > > We had a lot of problems with UBC: > - it's quite hard to set up the limit. > Why it's good to consume N entities of some resource but it's bad to consume N+1 ones? > per-process? per-user? per-thread? per-task? per-namespace? if nested? per-container? per-host? > To answer the questions host admin should have additional knowledge and skills. > > - Ok, we have set all limits. Some application hits it and fails. > It's quite hard to understand that application hits the limit, and failed due to this reason. > From users point of view, if some application does not work (stable enough) > inside container => containers are guilty. > > - It's quite hard to understand that failed application just want to increase limit X up to N entities. > > As result both host admins and container users was unhappy. > So after years of such fights we decided just to limit accounted > memory instead. Which is a perfectly fine justification. However the justification presented in the change log was that there is no existing limit, and that is what is factually wrong. Different kinds of limits serve different purposes. An accounting of how many instance of a resource has been used serve the purpose of detecting when an application has gone completely out of spec. Limits like you are implementing here are much better for just sharing and managing system resources. > Anyway, OOM-killer must know who consumed memory to select proper > target. The limits I am talking about are not useful to the OOM killer as usually the amount of resources that indicates something has gone wrong are too small to be a system-wide problem. So please just correct the justification in the commit message and I will be happy. Eric