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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 65C11C00140 for ; Mon, 22 Aug 2022 00:25:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231918AbiHVAZT (ORCPT ); Sun, 21 Aug 2022 20:25:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41646 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232075AbiHVAZP (ORCPT ); Sun, 21 Aug 2022 20:25:15 -0400 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 383AE201A8 for ; Sun, 21 Aug 2022 17:25:14 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id u15so9592978ejt.6 for ; Sun, 21 Aug 2022 17:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=vOM6Qk7H6503nwlxurWDnApj6tGcPYJKuggwnA4Q7DI=; b=d18GG+Bt516p+zMinyCQn18btHPsTUkM8kPzrVj0qRlWdy2iXgPx5SdfNKsgRcQ5+t OtpT4LYrHOqGSPN6EtuMYhEn51cgY1lIg1cVM4bqJBczwtMS70sLDPg356P2VE3PM9Dh mgRZekRTLn1Ac3RMfhbmkkN+PXDbsIU/PgXaHy/nHlK1uWtZJVQNzXTxZ/9TdY4yv7E7 6YRljr0tzGJfVO75aEh2zLCwUUaQb+K9LDB+6+a6DUjZevqZX+VoHbDggFmctnlqzlJc uJuGiXe1qObFP1Y+nN/gYcpwbAf8zmYaSbZfrL1rUOPvdz8Vng8leg9pLCE7NFHmnv79 eBNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=vOM6Qk7H6503nwlxurWDnApj6tGcPYJKuggwnA4Q7DI=; b=0ULN47uvk0a1bU0l3xkHGxdQExJKuF2vWg9Fg+JUhB4+mTP8rGQ/ZUX5M8sgU6C6jG wKRp2udq6wyZqlz73LGTR7wYgvL5lICQiXlm0qSMZSiTjzKeDYrMFOoCkGJHht7LwrY8 1YK+wHstPZJECu7aXxG+PcvoIczPuzIh4WZsFHfzp+984dZz8sx6rjvv5QG0OE2rZVSG ay3WmH8yGOU0iruuxqbE5Mqc8425p09r9MFWCXSzIX2WO0LXWKm1cElC+6wndjey92H2 Ok/gMgkin2gv1zUpBtksPwYAnwJkvQX9WYHueBgxzgukloARh68SHKHEC5JQ76rqWw+Z 6wgw== X-Gm-Message-State: ACgBeo3wJ2jjgrZLI7uU/KZ8GmdXnOS85lbNqiB/orMC8TnYiNT3tudd oskWtcAJQgRcFrhTsCy4EBbyakupeAe9jEwHzBhWmA== X-Google-Smtp-Source: AA6agR4puzJX0PrJauJDGDb6lfb25cap5PHs14UeMXH8C4YJFfUFZ1L+OkYEALZgFj/wkeiWFQR2zpRpgYIcHjsWDeE= X-Received: by 2002:a17:907:608b:b0:731:8a9d:5a2d with SMTP id ht11-20020a170907608b00b007318a9d5a2dmr11502290ejc.443.1661127912457; Sun, 21 Aug 2022 17:25:12 -0700 (PDT) MIME-Version: 1.0 References: <20220822001737.4120417-1-shakeelb@google.com> <20220822001737.4120417-4-shakeelb@google.com> In-Reply-To: <20220822001737.4120417-4-shakeelb@google.com> From: Soheil Hassas Yeganeh Date: Sun, 21 Aug 2022 20:24:36 -0400 Message-ID: Subject: Re: [PATCH 3/3] memcg: increase MEMCG_CHARGE_BATCH to 64 To: Shakeel Butt Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Eric Dumazet , Feng Tang , Oliver Sang , Andrew Morton , lkp@lists.01.org, cgroups@vger.kernel.org, linux-mm , netdev , linux-kernel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Aug 21, 2022 at 8:18 PM Shakeel Butt wrote: > > For several years, MEMCG_CHARGE_BATCH was kept at 32 but with bigger > machines and the network intensive workloads requiring througput in > Gbps, 32 is too small and makes the memcg charging path a bottleneck. > For now, increase it to 64 for easy acceptance to 6.0. We will need to > revisit this in future for ever increasing demand of higher performance. > > Please note that the memcg charge path drain the per-cpu memcg charge > stock, so there should not be any oom behavior change. > > To evaluate the impact of this optimization, on a 72 CPUs machine, we > ran the following workload in a three level of cgroup hierarchy with top > level having min and low setup appropriately. More specifically > memory.min equal to size of netperf binary and memory.low double of > that. > > $ netserver -6 > # 36 instances of netperf with following params > $ netperf -6 -H ::1 -l 60 -t TCP_SENDFILE -- -m 10K > > Results (average throughput of netperf): > Without (6.0-rc1) 10482.7 Mbps > With patch 17064.7 Mbps (62.7% improvement) > > With the patch, the throughput improved by 62.7%. > > Signed-off-by: Shakeel Butt > Reported-by: kernel test robot Nice! Acked-by: Soheil Hassas Yeganeh > --- > include/linux/memcontrol.h | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h > index 4d31ce55b1c0..70ae91188e16 100644 > --- a/include/linux/memcontrol.h > +++ b/include/linux/memcontrol.h > @@ -354,10 +354,11 @@ struct mem_cgroup { > }; > > /* > - * size of first charge trial. "32" comes from vmscan.c's magic value. > - * TODO: maybe necessary to use big numbers in big irons. > + * size of first charge trial. > + * TODO: maybe necessary to use big numbers in big irons or dynamic based of the > + * workload. > */ > -#define MEMCG_CHARGE_BATCH 32U > +#define MEMCG_CHARGE_BATCH 64U > > extern struct mem_cgroup *root_mem_cgroup; > > -- > 2.37.1.595.g718a3a8f04-goog >