From patchwork Fri Mar 17 13:44:48 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Michal Hocko X-Patchwork-Id: 13179068 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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 770F7C74A5B for ; Fri, 17 Mar 2023 13:44:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 045436B0075; Fri, 17 Mar 2023 09:44:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F37626B0078; Fri, 17 Mar 2023 09:44:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DFF026B007B; Fri, 17 Mar 2023 09:44:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id D30EF6B0075 for ; Fri, 17 Mar 2023 09:44:58 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 9F7D7AC292 for ; Fri, 17 Mar 2023 13:44:58 +0000 (UTC) X-FDA: 80578511076.17.458AF64 Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) by imf12.hostedemail.com (Postfix) with ESMTP id ACDAF4001D for ; Fri, 17 Mar 2023 13:44:55 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none); spf=pass (imf12.hostedemail.com: domain of mstsxfx@gmail.com designates 209.85.208.42 as permitted sender) smtp.mailfrom=mstsxfx@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679060695; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vJPMQdWRr2R62+6qFAGrbR0pxQ+XXGNRMUC/h0VNtm0=; b=Z9DobfjYuNvkYykMtIF/NxO3NBJ5npkmdSNPUNmPqVSxXoXMOG5QbhQcIPI3K078TtjJgu PaBQ+TBtZDW6zhq1b0mwf/gbGOTTqqo/SOAOIr+TUBQjTmH02srx7DJQ74hxB59Nd3H52w crZ9kASxeMYDDCYnv8ql18Rn+sVH1wk= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none); spf=pass (imf12.hostedemail.com: domain of mstsxfx@gmail.com designates 209.85.208.42 as permitted sender) smtp.mailfrom=mstsxfx@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679060695; a=rsa-sha256; cv=none; b=YK9KSQXnp8PhZD3IBrXMwT6441zCKWGw2gcaGJcyNVNGlfNHpQhhtPZJ5mEx+qZbpZAaWd kxlX6izBb1n0KgziixIUImIdHRCQkuD5tRI78/fwF7BZzC5JWEsm/Ti0DI3sqo6a6g2MQe aIW7IiOEOPTfRnr0xHw4eYRzgwIQt6M= Received: by mail-ed1-f42.google.com with SMTP id o12so20509856edb.9 for ; Fri, 17 Mar 2023 06:44:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679060694; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vJPMQdWRr2R62+6qFAGrbR0pxQ+XXGNRMUC/h0VNtm0=; b=FBWkD26qvzfcbU4bT82BzdiRhDkuPdyBoG/hdpQKXmvnbPjMUPxhgqZt6rrLiWMFuH wh+FtvVPu3Y2gObBHtkwwnIRF9RsFaVNzZzQ/yd1ZcMSmdrlHr8XqzXuJtUTuvT89AGa z/RNnsylH+hhugPvG0TLfOUhRH1nJIVe5lwDWt0YKVvMTIOHmBXyei0txLHKgtMZp0FK DmbMPIKHX6ZB6gxCnuehzkRRv4GWP1TTR45Cdz0WXPeiMzrS6+W7pdwtd3SuRecFMM/D C/St8Iu11Ik4GqUUnpRZh8I9zqLvOaViF/cLE4gcZYdXhiI/80ly9Pr2iOS0XB/9VRdY T+Tg== X-Gm-Message-State: AO0yUKVUc5MNFTzfNiSuzrM36C9cHL9JLXnV96OCdpevA6MBgx6gL2/l gxg2n0vQMXffb20CHc58WiQ= X-Google-Smtp-Source: AK7set83jXniV558MlOBbZXcyh1vr8063l9PNIhAzz51dJmEJsUiFtl0X65tzwCOY8u2W3NER4j7yg== X-Received: by 2002:a17:906:eec2:b0:92d:46f1:dc68 with SMTP id wu2-20020a170906eec200b0092d46f1dc68mr17325149ejb.67.1679060694390; Fri, 17 Mar 2023 06:44:54 -0700 (PDT) Received: from localhost.localdomain (85-160-41-201.reb.o2.cz. [85.160.41.201]) by smtp.gmail.com with ESMTPSA id gz14-20020a170906f2ce00b00923221f4062sm999273ejb.112.2023.03.17.06.44.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Mar 2023 06:44:54 -0700 (PDT) From: Michal Hocko To: Andrew Morton , Leonardo Bras Cc: Frederic Weisbecker , Peter Zijlstra , Thomas Gleixner , Marcelo Tosatti , Johannes Weiner , Roman Gushchin , Shakeel Butt , Muchun Song , LKML , , Michal Hocko , Frederic Weisbecker Subject: [PATCH 2/2] memcg: do not drain charge pcp caches on remote isolated cpus Date: Fri, 17 Mar 2023 14:44:48 +0100 Message-Id: <20230317134448.11082-3-mhocko@kernel.org> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20230317134448.11082-1-mhocko@kernel.org> References: <20230317134448.11082-1-mhocko@kernel.org> MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: ACDAF4001D X-Stat-Signature: r1inac1hjp7zf4ko1efhmo3yp81zdfiu X-HE-Tag: 1679060695-196636 X-HE-Meta: U2FsdGVkX1+pDSVa9aThbiKa0VN4WlqLzaWvcoyeRyTCoSpB1kMpAxh3s4bmEf+Ro8oNFo9p1HzFg1bsmsxYA4oGLz4TFuikvMefQc5GDqZ8zBcU/dvpSZ3xFg7pQVYNcUbZzzCceEOhzGeG9Z5i/JRIItM8Rkz1XiRZQuNcVE3U5KD8b14OFIJ9v2WBgjcxnFozW6BeU52yST/6aULqWpgTjlxxk0DUvLxWYy88CJQWcoN0dlXlcgGn4CGyV5YfqHvIgO26iIFALHzkPmxSQ1+9Fu7zVy66ZErqteq1zbZcMxh680a73zHWl3/KlJT9pT0lqfetSTpdHQxe7V+e6Zb58He0o5mSohVvFohk9sP98ojpwXMUmrRuG1PvewWMyuMU9fSJ4/7jGc0pq1opGWvDFFwZf1GSuRdmOY2b8hwQZXsVFsxcbNV9UtepLNWYmYQMeni8CIhZU3M1BLh8RY1sWhcNB+yXyBEtIKQBJh+oe+w8htpR17597DdLI0VQ5GXeOI8PNBiUtj4vktw22MHWc2nTV+1DNfoiO1txquyxfjKwm9Ht7Ok83YqM+0dQycvLlX//x2jKe+//bi70LE9dyJLYc/g3ztIfij+0E5GsL4DiAfpkTaiUH7KOf582EiOYMQrHFww3zUCYPfp8OFGSKCNeOP6+U7Ah/n6K7X3w7uMaybhtVEVBKtMdHfMn9iI3glJHgmaNVuXPpvXA0yw9Ny5cqwrMBM603kJWtvq4Osm4vzZTFLWB/SRLF0erT29lC5uOZg9n/GLBjQBm1xwgf9xIeQ6vsxo+ThPC+c8ZJWRxR6NqHQjY2YXVoGwo72s/ha9SljbY0HvspHrPRe30FQsWEemMdekv6yR1ZsIPjz9E0L4kIIIQ2DcdOqNwIeprz6UfBFYTqwSraPzdJcbMRboDj/kyldsjABCD/20vt8cDvD0YdY2STKrtYevnXZrkC6UixSS2N+O42r1 qUhsHX5+ aUfX1RxFSZ2jYamH8+C0T6QuPfukLHwwMMw4IGiNAoF8nB4H4h8dcgqhZbE6yV7uzi1b0HCxaUCAq0B5RUR4dAHVGLBOibYQHAHuHDx+8joLLGCQaY5e5T8NzytbLqgdF4Fv2Xrf9UKzlZaFApO49R/Pz9zr/b30AS/j/sZteZ+5Mb22HzjxN1sieMKCnyuzxvVkO93/bU79Jz74QfSRYxDPenDjEQ7fiJXDDzFQStG5yXTvNrm+ZC8sCLWMMGP1ZfnZAANQAlxo8yXi2gS63MMaDCVXu0YxUVg3GtiplIsQe9lV+teTu2xppsthpj7DYBEjiah1Hm8SH0VLNyV5/Q3Mu1nrYa0tLW3HkTF7LVhsgSDnUtFzaK8OIB1znxg3I7ZoKQO1Y28idPuYPwTKa6CBlpgfR/pe3dvcUU9hc8ibcVcHhCaZLmXo2HANV0NUv1lL4NYfZaBbXFnxElTnsHuchClN4DxVHokaSki1pZ61jY+6//CEd4oPUjiW9hvvms3MduDl9ncykNwjRybfudBn7jklltP6tbtceofoEvKq2U5V5zp6w3xsQcymoaAtzFndnXDCQDmZqvnkkXl3AgZZ58uk5AZ+PWw0RydWUaHJg5MZO56yQSiOTgxOOLj04ewjtyK+0MgdSh5+88q9pRUajGUZpGWlrGxYLXLDaH0bUb08EvUiXkU5eP1sgLX3oySngDB/QkS2ftJs= 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: From: Michal Hocko Leonardo Bras has noticed that pcp charge cache draining might be disruptive on workloads relying on 'isolated cpus', a feature commonly used on workloads that are sensitive to interruption and context switching such as vRAN and Industrial Control Systems. There are essentially two ways how to approach the issue. We can either allow the pcp cache to be drained on a different rather than a local cpu or avoid remote flushing on isolated cpus. The current pcp charge cache is really optimized for high performance and it always relies to stick with its cpu. That means it only requires local_lock (preempt_disable on !RT) and draining is handed over to pcp WQ to drain locally again. The former solution (remote draining) would require to add an additional locking to prevent local charges from racing with the draining. This adds an atomic operation to otherwise simple arithmetic fast path in the try_charge path. Another concern is that the remote draining can cause a lock contention for the isolated workloads and therefore interfere with it indirectly via user space interfaces. Another option is to avoid draining scheduling on isolated cpus altogether. That means that those remote cpus would keep their charges even after drain_all_stock returns. This is certainly not optimal either but it shouldn't really cause any major problems. In the worst case (many isolated cpus with charges - each of them with MEMCG_CHARGE_BATCH i.e 64 page) the memory consumption of a memcg would be artificially higher than can be immediately used from other cpus. Theoretically a memcg OOM killer could be triggered pre-maturely. Currently it is not really clear whether this is a practical problem though. Tight memcg limit would be really counter productive to cpu isolated workloads pretty much by definition because any memory reclaimed induced by memcg limit could break user space timing expectations as those usually expect execution in the userspace most of the time. Also charges could be left behind on memcg removal. Any future charge on those isolated cpus will drain that pcp cache so this won't be a permanent leak. Considering cons and pros of both approaches this patch is implementing the second option and simply do not schedule remote draining if the target cpu is isolated. This solution is much more simpler. It doesn't add any new locking and it is more more predictable from the user space POV. Should the pre-mature memcg OOM become a real life problem, we can revisit this decision. Cc: Leonardo Brás Cc: Marcelo Tosatti Cc: Shakeel Butt Cc: Muchun Song Cc: Johannes Weiner Cc: Frederic Weisbecker Reported-by: Leonardo Bras Acked-by: Roman Gushchin Suggested-by: Roman Gushchin Signed-off-by: Michal Hocko Acked-by: Shakeel Butt --- mm/memcontrol.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 0524add35cae..12559c08d976 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -2366,7 +2366,7 @@ static void drain_all_stock(struct mem_cgroup *root_memcg) !test_and_set_bit(FLUSHING_CACHED_CHARGE, &stock->flags)) { if (cpu == curcpu) drain_local_stock(&stock->work); - else + else if (!cpu_is_isolated(cpu)) schedule_work_on(cpu, &stock->work); } }