Received: by 2002:a05:6a10:6d25:0:0:0:0 with SMTP id gq37csp1693683pxb; Mon, 13 Sep 2021 03:27:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzZXLawCq4cL6QtHZp0CMjy2WSgdDVC9VhjIrXfhp7PpuHJmiGMIFclKV5qEqdJOK9weM2Q X-Received: by 2002:aa7:cf15:: with SMTP id a21mr12348724edy.152.1631528852561; Mon, 13 Sep 2021 03:27:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631528852; cv=none; d=google.com; s=arc-20160816; b=jlo+ur5OFCAxqMdB4aYU0vVXKseAwZiSv20vjjQD5HLfUENQowU+5HnQda4Vd6z+1P m3p4cSjnqnX7drlH1ybT4/8Psl+QCz0krgARQjtNGVqoKDLUDFWDclEBZZKWQWvbOeTo l+3P8Qz07knsPtK+1r5sOWdPt0iDP2Xf+3MiuT1C7nnq7pQjt7XT1u9e16aOB35TsARF ztygQJkJYwI9B8TM2+chAUnLxJRWadY7Itv+jDKUzWuWZYuhUfFeX3eo9HFVVNYapTJu 8hsZ0+FhmQLWs5pBJrPXL1sfTOrPF15duSZIHlqeXuD2NtvRrXGravLvRb7Ip30MbLhS cG3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=TkHNL+ib7NjPWsL57OO6zVdK+l/V7nLiS/zl/t9RNEE=; b=IKrmsFQgZ23eqSo5usDFdmiJcws7dF/yT3Cc7dy7jTO2WI+czKlYGkDXKgZoWaOW4v ZGZUOCmZKevLgZG0w79jbyBPcHgauFhdcnq/5mxycNr5DxItFwBxR+8NUlCoTrQVSZKj 5QIBrmSKmDPL+RAjhlLd+8V2MVz3M4tH+3a3XhuOao56ZnpMgJTK3WIlkRjkbAn1zwk1 WnlhpyDgaiMb1dnlatoio9SRw4tm32UCH/N0tWSIE2eyowYxGxZ51Yrg1pwI62pR8/fj FTC+OHe03C0HTw2rEPOMDVuPtbGldKkjbXjHzeJwMEbfrzhn7AYcar6mTiGUx+RM34Hd 9bFw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=relay header.b=mJMKaH5P; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c29si3013327edj.67.2021.09.13.03.27.03; Mon, 13 Sep 2021 03:27:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=relay header.b=mJMKaH5P; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238711AbhIMJjR (ORCPT + 99 others); Mon, 13 Sep 2021 05:39:17 -0400 Received: from relay.sw.ru ([185.231.240.75]:36190 "EHLO relay.sw.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238675AbhIMJjQ (ORCPT ); Mon, 13 Sep 2021 05:39:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=virtuozzo.com; s=relay; h=Content-Type:MIME-Version:Date:Message-ID:From: Subject; bh=TkHNL+ib7NjPWsL57OO6zVdK+l/V7nLiS/zl/t9RNEE=; b=mJMKaH5Pr/TTWXM+k BEesbC+Nhe8eaboiOWdPHcU5U96lxPEXpN9qBs6mIIhOBWJukn/dMrao3+jSik9NoiDCJ433lNL1D iFTCZhUdXvw3FbwiTF/L4rZS0qQBqAMcRAEKv7t/zgTypsrXOeHh8j3HVW0/bYC89sjznMxIt5Pyg =; Received: from [10.93.0.56] by relay.sw.ru with esmtp (Exim 4.94.2) (envelope-from ) id 1mPiPV-001nw1-Lj; Mon, 13 Sep 2021 12:37:57 +0300 Subject: Re: [PATCH memcg] memcg: prohibit unconditional exceeding the limit of dying tasks To: Michal Hocko Cc: Johannes Weiner , Vladimir Davydov , Andrew Morton , Tetsuo Handa , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <5b06a490-55bc-a6a0-6c85-690254f86fad@virtuozzo.com> <8b98d44a-aeb2-5f5f-2545-ac2bd0c7049b@virtuozzo.com> From: Vasily Averin Message-ID: Date: Mon, 13 Sep 2021 12:37:56 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/13/21 11:39 AM, Michal Hocko wrote: > On Mon 13-09-21 10:51:37, Vasily Averin wrote: >> On 9/10/21 3:39 PM, Vasily Averin wrote: >>> The kernel currently allows dying tasks to exceed the memcg limits. >>> The allocation is expected to be the last one and the occupied memory >>> will be freed soon. >>> This is not always true because it can be part of the huge vmalloc >>> allocation. Allowed once, they will repeat over and over again. >> >>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >>> index 389b5766e74f..67195fcfbddf 100644 >>> --- a/mm/memcontrol.c >>> +++ b/mm/memcontrol.c >>> @@ -2622,15 +2625,6 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask, >>> if (gfp_mask & __GFP_ATOMIC) >>> goto force; >>> >>> - /* >>> - * Unlike in global OOM situations, memcg is not in a physical >>> - * memory shortage. Allow dying and OOM-killed tasks to >>> - * bypass the last charges so that they can exit quickly and >>> - * free their memory. >>> - */ >>> - if (unlikely(should_force_charge())) >>> - goto force; >>> - >> >> Should we keep current behaviour for (current->flags & PF_EXITING) case perhaps? > > Why? On this stage task really dies and mostly releases taken resources. It can allocate though, and this allocation can reach memcg limit due to the activity of parallel memcg threads. Noting bad should happen if we reject this allocation, because the same thing can happen in non-memcg case too. However I doubt misuse is possible here and we have possibility to allow graceful shutdown here. In other words: we are not obliged to allow such allocations, but we CAN do it because we hope that it is safe and cannot be misused. >> It is set inside do_exit only and (I hope) cannot trigger huge vmalloc allocations. > > Allocations in this code path should be rare but it is not like they are > non-existent. This is rather hard to review area spread at many places > so if we are deciding to make the existing model simpler (no bypassing) > then I would rather have no exceptions unless they are reaaly necessary > and document them if they are. Thank you, vasily Averin