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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 28C70C47083 for ; Wed, 2 Jun 2021 09:11:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BAFB56101C for ; Wed, 2 Jun 2021 09:11:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BAFB56101C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 36AF06B006C; Wed, 2 Jun 2021 05:11:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 31A886B006E; Wed, 2 Jun 2021 05:11:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1959A6B0070; Wed, 2 Jun 2021 05:11:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0098.hostedemail.com [216.40.44.98]) by kanga.kvack.org (Postfix) with ESMTP id D821F6B006C for ; Wed, 2 Jun 2021 05:11:44 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 62797181AC9B6 for ; Wed, 2 Jun 2021 09:11:44 +0000 (UTC) X-FDA: 78208216128.02.8494769 Received: from mail-oi1-f177.google.com (mail-oi1-f177.google.com [209.85.167.177]) by imf28.hostedemail.com (Postfix) with ESMTP id B2512200109A for ; Wed, 2 Jun 2021 09:11:31 +0000 (UTC) Received: by mail-oi1-f177.google.com with SMTP id f30so709097oij.7 for ; Wed, 02 Jun 2021 02:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jiAxINQdIi7+HKRfHkFG9l2vkzASih/fGHAjPl9o30o=; b=Lfml9qG8E5om9EGGt1K9NrtEPh3JmhHemfh/T9ecn4hRxiACaf+qtqZDkwaOb9trMG ixX+y+wRuf9EwKeYGeMFgWmTx4j4EFKRvSYA0T9z4yZrOudlee98LFKNYwrCY3zjbdkC yQQQEGXE9yiZwWEN3sZma/nlj+w6IZ+I+qQMga77fgthsNu9DMlV21wJIUt5FhABt4JQ 8HcqQe7gyou6nJbv/rShsG5Mf/3ioXoGQkS3DDgwQ54l46DBN0WZbM8JMiodb55t0ppq I9dFPFDNvA7BTLTCQVG/Q3qItNTBfcihwoRp5Zum/8gMvXIPSUYGLALNE+vB3aSk88YP KodA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jiAxINQdIi7+HKRfHkFG9l2vkzASih/fGHAjPl9o30o=; b=oXNg3lAmSh4kyCgrHM126a15Z4Nc+7FNUy4x/HONSjxgk6S0+AbotWlNYeZ8qe+BCw ajaYk6aL8m2BQzKqIfkk+aOkpwrL26gct/NFAond/TLtAobS0By0Y1ISm9MtUDk0H1ee cvi6v20EtK8T0ZcJdQqof+cjKMy4eI3vB6coY513iGCCFxd3zvMNlYD28VmFWCVH+wqK oFXe8zeOnBIb8Ah82IA9TVqqwgHgv4zQnOAoUzkx93/ZdBMAwKU0WtH+tsfUn59GOLoV jk4iPLouvAY8XMK1HFOM2tIWsUsM98W76UnNyb1ZSGcqGzV+Gbzhu4x+Upvb62rR3xfG o4nA== X-Gm-Message-State: AOAM530+NAWGa9l6dVjR1BO3m3cqzBT9eWaFRIOHJYyHtdN1oA/P1IDd mxINYg1GJTELAC61ufKoJxIgN62fHQaFHJ6899k= X-Google-Smtp-Source: ABdhPJxt0e62W0fleD+lVbVQs4PUfIpjRBhm4weeIQP47c+R5HbP+Sq1IvFsgmUWw4T7ULWm3dqQvJYL0ozfi+QiIqI= X-Received: by 2002:aca:fcca:: with SMTP id a193mr3306773oii.40.1622625103325; Wed, 02 Jun 2021 02:11:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: yulei zhang Date: Wed, 2 Jun 2021 17:11:32 +0800 Message-ID: Subject: Re: [RFC 0/7] Introduce memory allocation speed throttle in memcg To: Chris Down Cc: Shakeel Butt , Tejun Heo , Zefan Li , Johannes Weiner , Christian Brauner , Cgroups , benbjiang@tencent.com, Wanpeng Li , Yulei Zhang , Linux MM , Michal Hocko , Roman Gushchin Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: B2512200109A Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=Lfml9qG8; spf=pass (imf28.hostedemail.com: domain of yuleikernel@gmail.com designates 209.85.167.177 as permitted sender) smtp.mailfrom=yuleikernel@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam04 X-Stat-Signature: 9i7raoo7yuubcqzr4b8e44u397pc9mze X-HE-Tag: 1622625091-382539 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Jun 1, 2021 at 10:45 PM Chris Down wrote: > > yulei zhang writes: > >Yep, dynamically adjust the memory.high limits can ease the memory pressure > >and postpone the global reclaim, but it can easily trigger the oom in > >the cgroups, > > To go further on Shakeel's point, which I agree with, memory.high should > _never_ result in memcg OOM. Even if the limit is breached dramatically, we > don't OOM the cgroup. If you have a demonstration of memory.high resulting in > cgroup-level OOM kills in recent kernels, then that needs to be provided. :-) You are right, I mistook it for max. Shakeel means the throttling during context switch which uses memory.high as threshold to calculate the sleep time. Currently it only applies to cgroupv2. In this patchset we explore another idea to throttle the memory usage, which rely on setting an average allocation speed in memcg. We hope to suppress the memory usage in low priority cgroups when it reaches the system watermark and still keep the activities alive. From mboxrd@z Thu Jan 1 00:00:00 1970 From: yulei zhang Subject: Re: [RFC 0/7] Introduce memory allocation speed throttle in memcg Date: Wed, 2 Jun 2021 17:11:32 +0800 Message-ID: References: Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jiAxINQdIi7+HKRfHkFG9l2vkzASih/fGHAjPl9o30o=; b=Lfml9qG8E5om9EGGt1K9NrtEPh3JmhHemfh/T9ecn4hRxiACaf+qtqZDkwaOb9trMG ixX+y+wRuf9EwKeYGeMFgWmTx4j4EFKRvSYA0T9z4yZrOudlee98LFKNYwrCY3zjbdkC yQQQEGXE9yiZwWEN3sZma/nlj+w6IZ+I+qQMga77fgthsNu9DMlV21wJIUt5FhABt4JQ 8HcqQe7gyou6nJbv/rShsG5Mf/3ioXoGQkS3DDgwQ54l46DBN0WZbM8JMiodb55t0ppq I9dFPFDNvA7BTLTCQVG/Q3qItNTBfcihwoRp5Zum/8gMvXIPSUYGLALNE+vB3aSk88YP KodA== In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Chris Down Cc: Shakeel Butt , Tejun Heo , Zefan Li , Johannes Weiner , Christian Brauner , Cgroups , benbjiang-1Nz4purKYjRBDgjK7y7TUQ@public.gmane.org, Wanpeng Li , Yulei Zhang , Linux MM , Michal Hocko , Roman Gushchin On Tue, Jun 1, 2021 at 10:45 PM Chris Down wrote: > > yulei zhang writes: > >Yep, dynamically adjust the memory.high limits can ease the memory pressure > >and postpone the global reclaim, but it can easily trigger the oom in > >the cgroups, > > To go further on Shakeel's point, which I agree with, memory.high should > _never_ result in memcg OOM. Even if the limit is breached dramatically, we > don't OOM the cgroup. If you have a demonstration of memory.high resulting in > cgroup-level OOM kills in recent kernels, then that needs to be provided. :-) You are right, I mistook it for max. Shakeel means the throttling during context switch which uses memory.high as threshold to calculate the sleep time. Currently it only applies to cgroupv2. In this patchset we explore another idea to throttle the memory usage, which rely on setting an average allocation speed in memcg. We hope to suppress the memory usage in low priority cgroups when it reaches the system watermark and still keep the activities alive.