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=-18.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham 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 03B0FC47088 for ; Wed, 26 May 2021 20:52:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 67314613F9 for ; Wed, 26 May 2021 20:52:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 67314613F9 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B7DF36B0036; Wed, 26 May 2021 16:52:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B54B26B006E; Wed, 26 May 2021 16:52:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A1C286B0070; Wed, 26 May 2021 16:52:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0093.hostedemail.com [216.40.44.93]) by kanga.kvack.org (Postfix) with ESMTP id 6F2966B0036 for ; Wed, 26 May 2021 16:52:39 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 0224E181AEF3C for ; Wed, 26 May 2021 20:52:39 +0000 (UTC) X-FDA: 78184580838.18.3F0AF2A Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf22.hostedemail.com (Postfix) with ESMTP id 8D074C0007DF for ; Wed, 26 May 2021 20:52:31 +0000 (UTC) Received: by mail-lf1-f48.google.com with SMTP id q1so4594297lfo.3 for ; Wed, 26 May 2021 13:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s4rL4ZNue6Ljpbr80Um7+WtGuIj1VHDvK86mKdNmljQ=; b=sou9i15FmrPZqYAW4inB0oXUePHg0dRp+/RQm+k2ORf8kOWxRnW3uSS71J5nwMaBqy hQwrVYiPiha0h2fhKhCMQfklVYVgAvDFzKiH3OJ7eYfJOCjlA7yXPGZB3K6QokT2kDbE BaWSb6lnnvAEsw38nWWwbYGzjCNEgHmgtKm3rJIgiou4Av8AKKLfD706jIBaq1MJBUKY ewD3FlJtjbTCsOOIoDR6QHYJvjvMMPQlN5Tq1aWIdWifiHynqj6GwJmLEH4DCBa6Egsf y4tn2m1jfxW8EmFyHq6X1J03bsASNtdsmlS6BqBAvNJzfzK/bSYTX6lA0jqM2zKpeu3P 531Q== 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=s4rL4ZNue6Ljpbr80Um7+WtGuIj1VHDvK86mKdNmljQ=; b=HTndxICWtb1NVXmmP5z5Yapi7U4Ayxlfd54IPlm465FEvqJeNC6VGwFSthvvPq01Xt l5Cc5oBo5stprFsHeaTVCG9THOR1RoQ3SgEOt0BadYnFvstseoHwF3JdY+2ezrLTpP0K kJfH0NpFurCjxqFD279WevPOlVv0LuSyWsLYrJBBviCtlEtRloZVdOB+LAFAz+rmYf1f D2AaX0/qjFlhHsn6a3Kcn+XCs5jRrs0eeUZZljKZOlpRCC2jCycfO/bN0+SjMXI5mKA4 HQXzd9Lz2oyPL+KFWivRJlMXJMbgYRURz8OKmA7+XYH63BCLWxq6VpQryQQiBlgLklt1 D1MA== X-Gm-Message-State: AOAM531PfPPnDfegjV7J6MltKjIinm4RoCbaVucD78cvgPN5UNQVBqQl 1ZPXWnuKxELFMzogc9AxYcOQjVoB5jP+V2VfyfxXIQ== X-Google-Smtp-Source: ABdhPJwbnWpyjCdp46SN7EoPPCbkv3U+ZcVSvpKDfnIKAI1oe0JpIh3gcZhBR4hmFx7O7/PlK040iDkwytg1jCn3FEo= X-Received: by 2002:a05:6512:3da3:: with SMTP id k35mr3254389lfv.347.1622062356909; Wed, 26 May 2021 13:52:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Shakeel Butt Date: Wed, 26 May 2021 13:52:25 -0700 Message-ID: Subject: Re: [RFC 0/7] Introduce memory allocation speed throttle in memcg To: yulei zhang 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" X-Rspamd-Queue-Id: 8D074C0007DF Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=sou9i15F; spf=pass (imf22.hostedemail.com: domain of shakeelb@google.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=shakeelb@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam04 X-Stat-Signature: zdigzk678ttf367se8iagc5n1hw88fwt X-HE-Tag: 1622062351-881706 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: 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. > 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. > > 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: Shakeel Butt Subject: Re: [RFC 0/7] Introduce memory allocation speed throttle in memcg Date: Wed, 26 May 2021 13:52:25 -0700 Message-ID: References: Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s4rL4ZNue6Ljpbr80Um7+WtGuIj1VHDvK86mKdNmljQ=; b=sou9i15FmrPZqYAW4inB0oXUePHg0dRp+/RQm+k2ORf8kOWxRnW3uSS71J5nwMaBqy hQwrVYiPiha0h2fhKhCMQfklVYVgAvDFzKiH3OJ7eYfJOCjlA7yXPGZB3K6QokT2kDbE BaWSb6lnnvAEsw38nWWwbYGzjCNEgHmgtKm3rJIgiou4Av8AKKLfD706jIBaq1MJBUKY ewD3FlJtjbTCsOOIoDR6QHYJvjvMMPQlN5Tq1aWIdWifiHynqj6GwJmLEH4DCBa6Egsf y4tn2m1jfxW8EmFyHq6X1J03bsASNtdsmlS6BqBAvNJzfzK/bSYTX6lA0jqM2zKpeu3P 531Q== In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: yulei zhang 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 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. > 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. > > 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 >