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=-11.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT 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 03EA6C433EF for ; Tue, 21 Sep 2021 16:13:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AA31360ED8 for ; Tue, 21 Sep 2021 16:13:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AA31360ED8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id BAFBE6B0080; Tue, 21 Sep 2021 12:13:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AC3C36B0081; Tue, 21 Sep 2021 12:13:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8EF7B6B0082; Tue, 21 Sep 2021 12:13:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0224.hostedemail.com [216.40.44.224]) by kanga.kvack.org (Postfix) with ESMTP id 7F9866B0080 for ; Tue, 21 Sep 2021 12:13:46 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 341AA2BC1C for ; Tue, 21 Sep 2021 16:13:46 +0000 (UTC) X-FDA: 78612076452.23.0DEAF4A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf26.hostedemail.com (Postfix) with ESMTP id D02A020019E7 for ; Tue, 21 Sep 2021 16:13:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1632240825; h=from:from: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; bh=qpu+HTkDrTU2emAVPYaio1EuujPd/r4QIzzzcyyaBgg=; b=JsHdnVtFe//h5AV8Q3s32ucXKU8qSNPDRxl6pwdf7hIzrQhDE/2zzR4qTKnRZG/yXesVeD qxjGVG3tMeC2CHjjksg15fb6+AdHMHUB05G6iPsGgsn28O27wtmQ57aT6CU9sP4e/eElOh rUOr76opKzuy3XhINfwoinQtYeQa8us= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-338-1XQq340vNwyYg6sKNPnWCw-1; Tue, 21 Sep 2021 12:13:40 -0400 X-MC-Unique: 1XQq340vNwyYg6sKNPnWCw-1 Received: by mail-wr1-f70.google.com with SMTP id r5-20020adfb1c5000000b0015cddb7216fso9266433wra.3 for ; Tue, 21 Sep 2021 09:13:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=qpu+HTkDrTU2emAVPYaio1EuujPd/r4QIzzzcyyaBgg=; b=NPcpl7VfOiNjuTRCvq/r5h7CIHxwogy7hVWoJXz9B2MwuF/aiLxKcWSh99in4YPgep HMPWO+T2aNL/kYlPlWv0gKiAJSY6cQ6OgDZk5zvj4sOLFw6VgcVdj+d4jVN//08pliGt pR6CodCx0vGSb1n3K8sXjDBaUrNVKWnYHbBmVBCEo/cnrvHRmS4z1k0yJr6QPpFeBs/Z o7/VDOv7tEstj8zk6afNUZKU/+1Bd4RGtYonVbZG5JeKvUrjBGgvxw2+uEeOYr7TFDqW lDT5Lk6sDNBxJFTRzAsaL+eFftjeXkleK/iO8h8bnfAhKUaJJbdaZjr6rr5eoLfopv9u BPtg== X-Gm-Message-State: AOAM533vSq6a/NqpB83wjd0SftS3l7XHEZuct+M6wsAcdGWIy9WJQqA7 voLglJsSKqFa8IYNQGtjQY0ZCrYlaiK3/30h+LDRdsuruYKMzEFKxCJoovBxORCDomZLOaVsuf3 7S3pcfE0jbBg= X-Received: by 2002:a5d:6c6e:: with SMTP id r14mr8786541wrz.319.1632240813562; Tue, 21 Sep 2021 09:13:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwCaTYPwc/9t2AtLYmgJlq3XzRG6bZgmYBolkh1RNI380hxk+8ra/35JT3nNBei0WBHtrFC/g== X-Received: by 2002:a5d:6c6e:: with SMTP id r14mr8786498wrz.319.1632240813317; Tue, 21 Sep 2021 09:13:33 -0700 (PDT) Received: from vian.redhat.com ([2a0c:5a80:1d03:b900:c3d1:5974:ce92:3123]) by smtp.gmail.com with ESMTPSA id t1sm19786477wrz.39.2021.09.21.09.13.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Sep 2021 09:13:32 -0700 (PDT) From: Nicolas Saenz Julienne To: akpm@linux-foundation.org, frederic@kernel.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, tglx@linutronix.de, cl@linux.com, peterz@infradead.org, juri.lelli@redhat.com, mingo@redhat.com, mtosatti@redhat.com, nilal@redhat.com, mgorman@suse.de, ppandit@redhat.com, williams@redhat.com, bigeasy@linutronix.de, anna-maria@linutronix.de, linux-rt-users@vger.kernel.org, Nicolas Saenz Julienne Subject: [PATCH 0/6] mm: Remote LRU per-cpu pagevec cache/per-cpu page list drain support Date: Tue, 21 Sep 2021 18:13:18 +0200 Message-Id: <20210921161323.607817-1-nsaenzju@redhat.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="US-ASCII" X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: D02A020019E7 Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=JsHdnVtF; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf26.hostedemail.com: domain of nsaenzju@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=nsaenzju@redhat.com X-Stat-Signature: 61r9ms4z3edq4fkpbr4dw3rr3yxrhb81 X-HE-Tag: 1632240825-553470 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000020, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: This series introduces an alternative locking scheme around mm/swap.c's p= er-cpu LRU pagevec caches and mm/page_alloc.c's per-cpu page lists which will al= low for remote CPUs to drain them. Currently, only a local CPU is permitted t= o change its per-cpu lists, and it's expected to do so, on-demand, whenever= a process demands it (by means of queueing an drain task on the local CPU).= Most systems will handle this promptly, but it'll cause problems for NOHZ_FULL= CPUs that can't take any sort of interruption without breaking their functiona= l guarantees (latency, bandwidth, etc...). Having a way for these processes= to remotely drain the lists themselves will make co-existing with isolated C= PUs possible, at the cost of more constraining locks. Fortunately for non-NOHZ_FULL users, the alternative locking scheme and r= emote drain code are conditional to a static key which is disabled by default. = This guarantees minimal functional or performance regressions. The feature wil= l only be enabled if NOHZ_FULL's initialization process was successful. This work is based on a previous series by Thomas Gleixner, Anna-Maria Gleixner, and Sebastian Andrzej Siewior[1]. [1] https://patchwork.kernel.org/project/linux-mm/patch/20190424111208.24= 459-3-bigeasy@linutronix.de/ Nicolas Saenz Julienne (6): mm/swap: Introduce lru_cpu_needs_drain() mm/swap: Introduce alternative per-cpu LRU cache locking mm/swap: Allow remote LRU cache draining mm/page_alloc: Introduce alternative per-cpu list locking mm/page_alloc: Allow remote per-cpu page list draining sched/isolation: Enable 'remote_pcpu_cache_access' on NOHZ_FULL systems kernel/sched/isolation.c | 9 +- mm/internal.h | 2 + mm/page_alloc.c | 111 ++++++++++++++++----- mm/swap.c | 202 ++++++++++++++++++++++++++++++--------- 4 files changed, 253 insertions(+), 71 deletions(-) --=20 2.31.1