Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp82865rwe; Wed, 24 Aug 2022 17:33:35 -0700 (PDT) X-Google-Smtp-Source: AA6agR57LDLEJrBPSAA/1aqgUhsjCJ1mKGZnDBzU09hR73MRayZRKUKeLL57Sq8xht/cusyfEXY6 X-Received: by 2002:a65:45cb:0:b0:41b:87ad:2a75 with SMTP id m11-20020a6545cb000000b0041b87ad2a75mr1158893pgr.604.1661387615235; Wed, 24 Aug 2022 17:33:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661387615; cv=none; d=google.com; s=arc-20160816; b=gM2O6UhLAIL03tyedTG/7SJ7XLc01O/Vb3Dp6O8kroJ1/qXbRxx0NOabKnME5Gjqtq jfSb0pWPTfV+fmdleR62v5DcmMsLZkiAKtXSO5TadT3IXK372gkP5ROy0L1au4OrVuzp YbObLXs42C1cZqJEgxyibAIZsYiJPIKvaYgk5AEjy78/3QoWgu+jwYm7SDnRZl9m/7lu oHFANNnkQ7ySQkBtZJuKUmGL9n5Fpu73pMs7FsWZNdgUwxa7nhqk+3c6guzCy3x8Inug nCyfwT1o8cGKrt7IOs14qBZ697TiExp9XDElSc0Q4vOLtbNNx+rzychc7hhuH9lEH5VU 6LHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:references:mime-version :message-id:in-reply-to:date:dkim-signature; bh=X0aXbVnjIsqv6IZlugAyzwT5Jn0BIh8DUeidfr3NTwU=; b=RDFlor+vHWW55NluJZZnQG1bKWbdIDyKCYc4KCvmfLk7qwz3EJUp+HQho8qqwign1h mU0Rba7CMs/Ep1AJRVh64iE61ub2uRezKWOJn/wCmjzA8dmcAsdlLaw/LkHspHojbP8j HlXlwVzSIUhUiEH2JP8UihKTyhumMyX8LIE6fBqd1W1FAg+f/VcQ1WMKp6E+1SQmk7P4 D+wQj4FSGAVUcvMeK56r42OSGymYJmfaLe3kZmuFAlLwM6wy8LwX+KxXZmetQNkXoDKW Hl4jD3IXrml58z3iQ1s4z6PgB3XsBcOzr9QRG+WX8MHxHMy/VqX+NiKakQxJQyV4oNvj O9ZQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=pizx5jtb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id jo19-20020a170903055300b001713e8ccf07si5848540plb.376.2022.08.24.17.32.59; Wed, 24 Aug 2022 17:33:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=pizx5jtb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230414AbiHYAFd (ORCPT + 99 others); Wed, 24 Aug 2022 20:05:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59528 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230439AbiHYAFa (ORCPT ); Wed, 24 Aug 2022 20:05:30 -0400 Received: from mail-pf1-x44a.google.com (mail-pf1-x44a.google.com [IPv6:2607:f8b0:4864:20::44a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D38DE65818 for ; Wed, 24 Aug 2022 17:05:28 -0700 (PDT) Received: by mail-pf1-x44a.google.com with SMTP id c135-20020a624e8d000000b0053617082770so6397224pfb.8 for ; Wed, 24 Aug 2022 17:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:references:mime-version:message-id:in-reply-to :date:from:to:cc; bh=X0aXbVnjIsqv6IZlugAyzwT5Jn0BIh8DUeidfr3NTwU=; b=pizx5jtbolFH74HPRP+JXhQp2kt4f4Gvo5c8BahsoqOTkDMpUC21gySwAqRyERcsxp RxiJ7ZTDPE4UhNy7ASniRjeSQfLiOp7A52n7UcNJaRcgoNbt5hJSwRUZ2tkpQ2Q3baJ8 4cQTvaVR9bW07R8J1S2oVdOXktAWKIkD5EuCtdCBJ7DOtVg6boyaG97qE7d++5ICk+ah 2bvtXldISERsWobmMdnkvmtae/Ky7rkElbKgMUHUw96nEyyamlUTC7zNBQtNgsfupFiv 1ehcbs9orlmOrXVk8eSGqQ8mVmxBPOLIJjcaHvhtzjRgZpozbsey811NndPtqmQMB85j qK7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:references:mime-version:message-id:in-reply-to :date:x-gm-message-state:from:to:cc; bh=X0aXbVnjIsqv6IZlugAyzwT5Jn0BIh8DUeidfr3NTwU=; b=NZtdyvxnGjuNSH5gNCR2e1jxMjWeEp6yFzNMsMjAcFzOPMC2a5oMwwsUQ88VspRIoP GD2f7VQ4+pFCu1sktzzYkug8p9qY5lUdv/nvWxVg+xRaqmzdItcaivBb7ZT1upvQFVIV 8g4BYP0hXIjdynsLPEnuxDztdHt7OQDOHzr1RHiRo7o6Cc0ImTb/XsmihVuXNwOS1dcD LZyBoSNQRatAEdLu/M8tamKUd75C2zvwZPhvOXPRtrQDWEeX21og5uxx2KBXTGROCzov c0Farcqz5bNWW92NBbuc7+Zd9ODEv8ueHTT2PjDZyyfm531QFUrEJHt2ECN/MMxq4IlS gdPQ== X-Gm-Message-State: ACgBeo39JD/jrnH40OnUqK6kLiiCGwwhCBtIrXY9OhE1X9UAww2D8Vza 7iEyKMjBLX1j1GSTXujXkycVN5x+hHIVRw== X-Received: from shakeelb.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:262e]) (user=shakeelb job=sendgmr) by 2002:a05:6a00:4147:b0:52e:2d56:17c8 with SMTP id bv7-20020a056a00414700b0052e2d5617c8mr1426905pfb.51.1661385928246; Wed, 24 Aug 2022 17:05:28 -0700 (PDT) Date: Thu, 25 Aug 2022 00:05:04 +0000 In-Reply-To: <20220825000506.239406-1-shakeelb@google.com> Message-Id: <20220825000506.239406-2-shakeelb@google.com> Mime-Version: 1.0 References: <20220825000506.239406-1-shakeelb@google.com> X-Mailer: git-send-email 2.37.1.595.g718a3a8f04-goog Subject: [PATCH v2 1/3] mm: page_counter: remove unneeded atomic ops for low/min From: Shakeel Butt To: Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song Cc: "=?UTF-8?q?Michal=20Koutn=C3=BD?=" , Eric Dumazet , Soheil Hassas Yeganeh , Feng Tang , Oliver Sang , Andrew Morton , lkp@lists.01.org, cgroups@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Shakeel Butt Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org For cgroups using low or min protections, the function propagate_protected_usage() was doing an atomic xchg() operation irrespectively. We can optimize out this atomic operation for one specific scenario where the workload is using the protection (i.e. min > 0) and the usage is above the protection (i.e. usage > min). This scenario is actually very common where the users want a part of their workload to be protected against the external reclaim. Though this optimization does introduce a race when the usage is around the protection and concurrent charges and uncharged trip it over or under the protection. In such cases, we might see lower effective protection but the subsequent charge/uncharge will correct it. 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 to see if this optimization is effective for the mentioned case. $ 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 14542.5 Mbps (38.7% improvement) With the patch, the throughput improved by 38.7% Signed-off-by: Shakeel Butt Reported-by: kernel test robot Acked-by: Soheil Hassas Yeganeh Reviewed-by: Feng Tang Acked-by: Roman Gushchin --- Changes since v1: - Commit message update with more detail on which scenario is getting optimized and possible race condition. mm/page_counter.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/mm/page_counter.c b/mm/page_counter.c index eb156ff5d603..47711aa28161 100644 --- a/mm/page_counter.c +++ b/mm/page_counter.c @@ -17,24 +17,23 @@ static void propagate_protected_usage(struct page_counter *c, unsigned long usage) { unsigned long protected, old_protected; - unsigned long low, min; long delta; if (!c->parent) return; - min = READ_ONCE(c->min); - if (min || atomic_long_read(&c->min_usage)) { - protected = min(usage, min); + protected = min(usage, READ_ONCE(c->min)); + old_protected = atomic_long_read(&c->min_usage); + if (protected != old_protected) { old_protected = atomic_long_xchg(&c->min_usage, protected); delta = protected - old_protected; if (delta) atomic_long_add(delta, &c->parent->children_min_usage); } - low = READ_ONCE(c->low); - if (low || atomic_long_read(&c->low_usage)) { - protected = min(usage, low); + protected = min(usage, READ_ONCE(c->low)); + old_protected = atomic_long_read(&c->low_usage); + if (protected != old_protected) { old_protected = atomic_long_xchg(&c->low_usage, protected); delta = protected - old_protected; if (delta) -- 2.37.1.595.g718a3a8f04-goog