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=-7.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,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 6EEFDC47082 for ; Mon, 31 May 2021 12:11:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 09C376135C for ; Mon, 31 May 2021 12:11:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 09C376135C 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 92FEF6B0074; Mon, 31 May 2021 08:11:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8DFD96B0075; Mon, 31 May 2021 08:11:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7593E6B0078; Mon, 31 May 2021 08:11:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0189.hostedemail.com [216.40.44.189]) by kanga.kvack.org (Postfix) with ESMTP id 44F886B0074 for ; Mon, 31 May 2021 08:11:21 -0400 (EDT) Received: from smtpin38.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id CFB538249980 for ; Mon, 31 May 2021 12:11:20 +0000 (UTC) X-FDA: 78201411120.38.21029FB Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) by imf20.hostedemail.com (Postfix) with ESMTP id 8CFA337B for ; Mon, 31 May 2021 12:11:05 +0000 (UTC) Received: by mail-ot1-f50.google.com with SMTP id h24-20020a9d64180000b029036edcf8f9a6so10913717otl.3 for ; Mon, 31 May 2021 05:11:20 -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=QabDEnSZP2Zk/nIpGBcw5lJ+v0F8frsBzEZMTlyQPGM=; b=bHgL3AKF8WE5bzHtyLSXl4V6zpvrAdWWLDQxf9SvFvoD9jSR2EevvzYsrBoZyTmCCL 8WFwvDZrAQ9wTTEdjtXQBOswe3RO9Ly7GhHQjLwNCxiCmBGVvEW7aYwLHivyeaLwIiB1 axN3APEE9GV/NZZJ7CZd/2rxGDQQ4rmpty8XVetA2+oIzjMGr0JiyvDMjgmPce1m8EoN fd//+c4gRQSfRS4XfVCwoz3HsSkpV/FLnwnWiLgQ6MKxPsVRnr4Xgnv9+I5YRZkCDoEi bL1eFxUuSrv7YxY+qOVTC9G26FiEOh2Pk5mywmxl15ayABi5FpGvPZ1JzyLxvjobedu+ CU+g== 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=QabDEnSZP2Zk/nIpGBcw5lJ+v0F8frsBzEZMTlyQPGM=; b=dToBK0xJGoLzVnSKWh1TjtgUnf7ycJvSrCYb08LEVLi5+rUjdeIPPzmd2x4rk5ZJnF 4ZcDCV3g9S16JBzKchsjn2YoiqVObC8yfl/w9kYWRi1Fh6caIbOzJ2IcsSdojirjjeeT H8s69xN+Hkn5XwoS0ScUTKRY0oIBpXutrBhg1dKl0OjyAQGjUQL2ww2L1W99k114vO4q aPPFDMf/vNdylCAzYakwd/mbnaWMSX8BlEAm7hU9ZLBa88ecGuc4uuRUFicA2tM17Da3 z/3sOGwSXk796JYCEy2MeLtlvqn4f/cjf6tw4hcmdQ3VZi1YuvQbeFpA4a/GB0bLBVCF vgxg== X-Gm-Message-State: AOAM533k1JdbJ4nvxmVb8KkE73gYvfLNWdUng3lE8hVO802tjZNcLXY1 G1bu/b6S8aUtvFNnxrwqGgzipU2ccNf/nPpvLOc= X-Google-Smtp-Source: ABdhPJwGNdECKffawoJYU1TW43FEozf9zue7wpsHD/KRczV5sAeo3LCsc8ydmrg7VN+TGkzS41g/9uAYwEqGiW1pTyg= X-Received: by 2002:a9d:71c8:: with SMTP id z8mr16518370otj.304.1622463079619; Mon, 31 May 2021 05:11:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: yulei zhang Date: Mon, 31 May 2021 20:11:08 +0800 Message-ID: Subject: Re: [RFC 0/7] Introduce memory allocation speed throttle in memcg To: Shakeel Butt Cc: 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" Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=bHgL3AKF; spf=pass (imf20.hostedemail.com: domain of yuleikernel@gmail.com designates 209.85.210.50 as permitted sender) smtp.mailfrom=yuleikernel@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 8CFA337B X-Stat-Signature: yqta7gjh6aj8y7u876jhfgfj5kpho5b1 X-HE-Tag: 1622463065-98910 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 Thu, May 27, 2021 at 4:52 AM Shakeel Butt wrote: > > Adding linux-mm and related folks. > > > > On Wed, May 26, 2021 at 9:18 AM wrote: > > > > From: Yulei Zhang > > > > In this patch set we present the idea to suppress the memory allocation > > speed in memory cgroup, which aims to avoid direct reclaim caused by > > memory allocation burst while under memory pressure. > > > > I am assuming here direct reclaim means global reclaim. > Yep. > > As minimum watermark could be easily broken if certain tasks allocate > > massive amount of memory in a short period of time, in that case it will > > trigger the direct memory reclaim and cause unacceptable jitters for > > latency critical tasks, such as guaranteed pod task in K8s. > > > > With memory allocation speed throttle(mst) mechanism we could lower the > > memory allocation speed in certian cgroup, usually for low priority tasks, > > so that could avoid the direct memory reclaim in time. > > Can you please explain why memory.high is not good enough for your > use-case? You can orchestrate the memory.high limits in such a way > that those certain cgroups hit their memory.high limit before causing > the global reclaim. You might need to dynamically adjust the limits > based on other workloads or unaccounted memory. > 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, which may not be suitable in certain usage cases when we want the services alive. Using throttle to suppress the allocation may help keep the activities and doesn't impact others. Thanks. > > > > And per-memcg interfaces are introduced under memcg tree, not visiable for > > root memcg. > > - //memory.alloc_bps > > - 0 -> means memory speed throttle disabled > > - non-zero -> value in bytes for memory allocation speed limits > > > > - //memory.stat:mst_mem_spd_max > > it records the max memory allocation speed of the memory cgroup in the > > last period of time slice > > > > - //memory.stat:mst_nr_throttled > > it represents the number of times for allocation throttling > > > > Yulei Zhang (7): > > mm: record total charge and max speed counter in memcg > > mm: introduce alloc_bps to memcg for memory allocation speed throttle > > mm: memory allocation speed throttle setup in hierarchy > > mm: introduce slice analysis into memory speed throttle mechanism > > mm: introduce memory allocation speed throttle > > mm: record the numbers of memory allocation throttle > > mm: introduce mst low and min watermark > > > > include/linux/memcontrol.h | 23 +++ > > include/linux/page_counter.h | 8 + > > init/Kconfig | 8 + > > mm/memcontrol.c | 295 +++++++++++++++++++++++++++++++++++ > > mm/page_counter.c | 39 +++++ > > 5 files changed, 373 insertions(+) > > > > -- > > 2.28.0 > > 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: Mon, 31 May 2021 20:11:08 +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=QabDEnSZP2Zk/nIpGBcw5lJ+v0F8frsBzEZMTlyQPGM=; b=bHgL3AKF8WE5bzHtyLSXl4V6zpvrAdWWLDQxf9SvFvoD9jSR2EevvzYsrBoZyTmCCL 8WFwvDZrAQ9wTTEdjtXQBOswe3RO9Ly7GhHQjLwNCxiCmBGVvEW7aYwLHivyeaLwIiB1 axN3APEE9GV/NZZJ7CZd/2rxGDQQ4rmpty8XVetA2+oIzjMGr0JiyvDMjgmPce1m8EoN fd//+c4gRQSfRS4XfVCwoz3HsSkpV/FLnwnWiLgQ6MKxPsVRnr4Xgnv9+I5YRZkCDoEi bL1eFxUuSrv7YxY+qOVTC9G26FiEOh2Pk5mywmxl15ayABi5FpGvPZ1JzyLxvjobedu+ CU+g== In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Shakeel Butt Cc: 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 Thu, May 27, 2021 at 4:52 AM Shakeel Butt wrote: > > Adding linux-mm and related folks. > > > > On Wed, May 26, 2021 at 9:18 AM wrote: > > > > From: Yulei Zhang > > > > In this patch set we present the idea to suppress the memory allocation > > speed in memory cgroup, which aims to avoid direct reclaim caused by > > memory allocation burst while under memory pressure. > > > > I am assuming here direct reclaim means global reclaim. > Yep. > > As minimum watermark could be easily broken if certain tasks allocate > > massive amount of memory in a short period of time, in that case it will > > trigger the direct memory reclaim and cause unacceptable jitters for > > latency critical tasks, such as guaranteed pod task in K8s. > > > > With memory allocation speed throttle(mst) mechanism we could lower the > > memory allocation speed in certian cgroup, usually for low priority tasks, > > so that could avoid the direct memory reclaim in time. > > Can you please explain why memory.high is not good enough for your > use-case? You can orchestrate the memory.high limits in such a way > that those certain cgroups hit their memory.high limit before causing > the global reclaim. You might need to dynamically adjust the limits > based on other workloads or unaccounted memory. > 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, which may not be suitable in certain usage cases when we want the services alive. Using throttle to suppress the allocation may help keep the activities and doesn't impact others. Thanks. > > > > And per-memcg interfaces are introduced under memcg tree, not visiable for > > root memcg. > > - //memory.alloc_bps > > - 0 -> means memory speed throttle disabled > > - non-zero -> value in bytes for memory allocation speed limits > > > > - //memory.stat:mst_mem_spd_max > > it records the max memory allocation speed of the memory cgroup in the > > last period of time slice > > > > - //memory.stat:mst_nr_throttled > > it represents the number of times for allocation throttling > > > > Yulei Zhang (7): > > mm: record total charge and max speed counter in memcg > > mm: introduce alloc_bps to memcg for memory allocation speed throttle > > mm: memory allocation speed throttle setup in hierarchy > > mm: introduce slice analysis into memory speed throttle mechanism > > mm: introduce memory allocation speed throttle > > mm: record the numbers of memory allocation throttle > > mm: introduce mst low and min watermark > > > > include/linux/memcontrol.h | 23 +++ > > include/linux/page_counter.h | 8 + > > init/Kconfig | 8 + > > mm/memcontrol.c | 295 +++++++++++++++++++++++++++++++++++ > > mm/page_counter.c | 39 +++++ > > 5 files changed, 373 insertions(+) > > > > -- > > 2.28.0 > >