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.8 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 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 B44DAC07E94 for ; Fri, 4 Jun 2021 10:21:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 43E1161404 for ; Fri, 4 Jun 2021 10:21:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 43E1161404 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 6057F6B0036; Fri, 4 Jun 2021 06:21:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5B5F86B006C; Fri, 4 Jun 2021 06:21:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 42ED96B006E; Fri, 4 Jun 2021 06:21:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0171.hostedemail.com [216.40.44.171]) by kanga.kvack.org (Postfix) with ESMTP id 13A596B0036 for ; Fri, 4 Jun 2021 06:21:27 -0400 (EDT) Received: from smtpin36.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 9C4CCC5D0 for ; Fri, 4 Jun 2021 10:21:26 +0000 (UTC) X-FDA: 78215649372.36.DB7565B Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com [209.85.167.173]) by imf13.hostedemail.com (Postfix) with ESMTP id 58ED4E007A64 for ; Fri, 4 Jun 2021 10:21:09 +0000 (UTC) Received: by mail-oi1-f173.google.com with SMTP id v22so9301666oic.2 for ; Fri, 04 Jun 2021 03:21:23 -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=kXNZFynTVd7Tj+4yCTxPtCHUxkYVTA9YmlhLOcTv9i4=; b=dEDQHphBkeNVUUe/39lXpjzvRnF/sgMO3KCzRZcCyvEN5dcy6fameRkVnBdx5YMW9D F6S17iSrJMCDdY4PEat3HygCOzxMJQUYE/xZ2V/31MxzglUH8ATcba4Wj7BCxrlk3/jQ 4lyIvJ8ao3l5q7NZQ0+z3C75iW9wobbdtOaZMNvT5RZUZHHiJbfREJoKWO8l8fdtUoNj 0e8htveobhzcJ9iNG7nf6DYSY1sLMYNsnMcKkmxFHcMAdf6vUFLNau2pGGAjLegxisJQ K6Ai+UdGN9nQ8bh2lXQnzZaqMyDvE74QJXHgzVIbAcJsNQSFQ6Gh57SZPaBHxS/KBBxr fRvQ== 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=kXNZFynTVd7Tj+4yCTxPtCHUxkYVTA9YmlhLOcTv9i4=; b=hnmv+pXb/tTWKhG2u9THvkDAZGmUmwEXvKvap5mYkSfWGvVSyEAxLVm/xJWmZ5nFsb c6I48KDwKzclgkut7+oMJ2nOrLShGCKGbIA4QhUwTW3QejWZ43AgOARkZsqm/nUG2Hpx k+dmn9itAHKozZeAcUIpp0SGc2fNGTwv7f1bn4e2TKraTRB9qX1G4tvjMB1rDfEPfsBt UPa6qStJ9dUWNagZW8YsggPxpDVh6B0mbEmZ30lsoVas39P728QGaZcG6K24ybVdVaCE goO3FVQP3uiggA//aL2snmGHLhYjNNCyyht4/rjJey+NlvKCe7K13GcY2gv9erTWakmb JPyg== X-Gm-Message-State: AOAM532DOT4QQwzWXRxjBNVAGeeaPCr63/aU27PzMEpUFRiH5Y8T5Ky/ EuAq8lFkxbmvRUYdRioyI0rEcmilGvo5S4Ti9Xk= X-Google-Smtp-Source: ABdhPJwJ/Emo2MVhtgktwC7wSZnmnR53U7Rv0ZOTYYt25aE++p9ooPfh+CjDF6KsRnp+bIFL9TztPhrgAo2P9GvcIfI= X-Received: by 2002:a05:6808:10d6:: with SMTP id s22mr10466980ois.96.1622801713604; Fri, 04 Jun 2021 03:15:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: yulei zhang Date: Fri, 4 Jun 2021 18:15:02 +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-Server: rspam01 X-Rspamd-Queue-Id: 58ED4E007A64 Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=dEDQHphB; spf=pass (imf13.hostedemail.com: domain of yuleikernel@gmail.com designates 209.85.167.173 as permitted sender) smtp.mailfrom=yuleikernel@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: nwefz81n61ibbqzxzbr1ixcqqa5e5cod X-HE-Tag: 1622802069-932260 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, Jun 3, 2021 at 7:38 PM Chris Down wrote: > > yulei zhang writes: > >Thanks. IMHO, there are differences between these two throttlings. > >memory.high is a per-memcg throttle which targets to limit the memory > >usage of the tasks in the cgroup. For the memory allocation speed throttle(MST), > >the purpose is to avoid the memory burst in cgroup which would trigger > >the global reclaim and affects the timing sensitive workloads in other cgroup. > >For example, we have two pods with memory overcommit enabled, one includes > >online tasks and the other has offline tasks, if we restrict the memory usage of > >the offline pod with memory.high, it will lose the benefit of memory overcommit > >when the other workloads are idle. On the other hand, if we don't > >limit the memory > >usage, it will easily break the system watermark when there suddenly has massive > >memory operations. If enable MST in this case, we will be able to > >avoid the direct > >reclaim and leverage the overcommit. > > Having a speed throttle is a very primitive knob: it's hard to know what the > correct values are for a user. That's one of the reasons why we've moved away > from that kind of tunable for blkio. > > Ultimately, if you want work-conserving behaviour, why not use memory.low? Thanks. But currently low and high are for cgroup v2 setting, do you think we'd better extend the same mechanism to cgroup v1? 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: Fri, 4 Jun 2021 18:15:02 +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=kXNZFynTVd7Tj+4yCTxPtCHUxkYVTA9YmlhLOcTv9i4=; b=dEDQHphBkeNVUUe/39lXpjzvRnF/sgMO3KCzRZcCyvEN5dcy6fameRkVnBdx5YMW9D F6S17iSrJMCDdY4PEat3HygCOzxMJQUYE/xZ2V/31MxzglUH8ATcba4Wj7BCxrlk3/jQ 4lyIvJ8ao3l5q7NZQ0+z3C75iW9wobbdtOaZMNvT5RZUZHHiJbfREJoKWO8l8fdtUoNj 0e8htveobhzcJ9iNG7nf6DYSY1sLMYNsnMcKkmxFHcMAdf6vUFLNau2pGGAjLegxisJQ K6Ai+UdGN9nQ8bh2lXQnzZaqMyDvE74QJXHgzVIbAcJsNQSFQ6Gh57SZPaBHxS/KBBxr fRvQ== 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 Thu, Jun 3, 2021 at 7:38 PM Chris Down wrote: > > yulei zhang writes: > >Thanks. IMHO, there are differences between these two throttlings. > >memory.high is a per-memcg throttle which targets to limit the memory > >usage of the tasks in the cgroup. For the memory allocation speed throttle(MST), > >the purpose is to avoid the memory burst in cgroup which would trigger > >the global reclaim and affects the timing sensitive workloads in other cgroup. > >For example, we have two pods with memory overcommit enabled, one includes > >online tasks and the other has offline tasks, if we restrict the memory usage of > >the offline pod with memory.high, it will lose the benefit of memory overcommit > >when the other workloads are idle. On the other hand, if we don't > >limit the memory > >usage, it will easily break the system watermark when there suddenly has massive > >memory operations. If enable MST in this case, we will be able to > >avoid the direct > >reclaim and leverage the overcommit. > > Having a speed throttle is a very primitive knob: it's hard to know what the > correct values are for a user. That's one of the reasons why we've moved away > from that kind of tunable for blkio. > > Ultimately, if you want work-conserving behaviour, why not use memory.low? Thanks. But currently low and high are for cgroup v2 setting, do you think we'd better extend the same mechanism to cgroup v1?