From: Frederic Weisbecker <frederic@kernel.org>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Frederic Weisbecker <frederic@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Valentin Schneider <vschneid@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
Vlastimil Babka <vbabka@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Oleg Nesterov <oleg@redhat.com>
Subject: [RFC PATCH 6/6] mm: Drain LRUs upon resume to userspace on nohz_full CPUs
Date: Tue, 25 Jun 2024 15:52:44 +0200 [thread overview]
Message-ID: <20240625135244.20227-7-frederic@kernel.org> (raw)
In-Reply-To: <20240625135244.20227-1-frederic@kernel.org>
LRUs can be drained through several ways. One of them may add disturbances
to isolated workloads while queuing a work at any time to any target,
whether running in nohz_full mode or not.
Prevent from that on isolated tasks with draining LRUs upon resuming to
userspace using the isolated task work framework.
It's worth noting that this is inherently racy against
lru_add_drain_all() remotely queueing the per CPU drain work and
therefore it prevents from the undesired disturbance only
*most of the time*.
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
---
include/linux/swap.h | 1 +
kernel/sched/isolation.c | 1 +
mm/swap.c | 5 ++++-
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/linux/swap.h b/include/linux/swap.h
index bd450023b9a4..bd6169c9cc14 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -393,6 +393,7 @@ extern void lru_add_drain(void);
extern void lru_add_drain_cpu(int cpu);
extern void lru_add_drain_cpu_zone(struct zone *zone);
extern void lru_add_drain_all(void);
+extern void lru_add_and_bh_lrus_drain(void);
void folio_deactivate(struct folio *folio);
void folio_mark_lazyfree(struct folio *folio);
extern void swap_setup(void);
diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
index 410df1fedc9d..68c70bea99e7 100644
--- a/kernel/sched/isolation.c
+++ b/kernel/sched/isolation.c
@@ -257,6 +257,7 @@ __setup("isolcpus=", housekeeping_isolcpus_setup);
#if defined(CONFIG_NO_HZ_FULL)
static void isolated_task_work(struct callback_head *head)
{
+ lru_add_and_bh_lrus_drain();
}
int __isolated_task_work_queue(void)
diff --git a/mm/swap.c b/mm/swap.c
index 67786cb77130..a4d7e3dc2a66 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -37,6 +37,7 @@
#include <linux/page_idle.h>
#include <linux/local_lock.h>
#include <linux/buffer_head.h>
+#include <linux/sched/isolation.h>
#include "internal.h"
@@ -521,6 +522,8 @@ void folio_add_lru(struct folio *folio)
fbatch = this_cpu_ptr(&cpu_fbatches.lru_add);
folio_batch_add_and_move(fbatch, folio, lru_add_fn);
local_unlock(&cpu_fbatches.lock);
+
+ isolated_task_work_queue();
}
EXPORT_SYMBOL(folio_add_lru);
@@ -765,7 +768,7 @@ void lru_add_drain(void)
* the same cpu. It shouldn't be a problem in !SMP case since
* the core is only one and the locks will disable preemption.
*/
-static void lru_add_and_bh_lrus_drain(void)
+void lru_add_and_bh_lrus_drain(void)
{
local_lock(&cpu_fbatches.lock);
lru_add_drain_cpu(smp_processor_id());
--
2.45.2
next prev parent reply other threads:[~2024-06-25 13:53 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-25 13:52 [RFC PATCH 0/6] mm: LRU drain flush on nohz_full Frederic Weisbecker
2024-06-25 13:52 ` [RFC PATCH 1/6] task_work: Provide means to check if a work is queued Frederic Weisbecker
2024-06-25 14:15 ` Oleg Nesterov
2024-06-25 15:16 ` Oleg Nesterov
2024-07-03 12:42 ` Frederic Weisbecker
2024-07-03 12:41 ` Frederic Weisbecker
2024-07-16 13:00 ` Valentin Schneider
2024-06-25 13:52 ` [RFC PATCH 2/6] sched/fair: Use task_work_queued() on numa_work Frederic Weisbecker
2024-07-16 13:00 ` Valentin Schneider
2024-06-25 13:52 ` [RFC PATCH 3/6] sched: Use task_work_queued() on cid_work Frederic Weisbecker
2024-07-16 13:00 ` Valentin Schneider
2024-06-25 13:52 ` [RFC PATCH 4/6] tick/nohz: Move nohz_full related fields out of hot task struct's places Frederic Weisbecker
2024-06-25 13:52 ` [RFC PATCH 5/6] sched/isolation: Introduce isolated task work Frederic Weisbecker
2024-06-26 13:27 ` Vlastimil Babka
2024-07-03 12:47 ` Frederic Weisbecker
2024-06-25 13:52 ` Frederic Weisbecker [this message]
2024-06-25 14:20 ` [RFC PATCH 6/6] mm: Drain LRUs upon resume to userspace on nohz_full CPUs Michal Hocko
2024-06-26 13:16 ` Vlastimil Babka
2024-06-27 6:54 ` Michal Hocko
2024-07-03 12:52 ` Frederic Weisbecker
2024-07-04 13:11 ` Michal Hocko
2024-07-17 13:21 ` Frederic Weisbecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240625135244.20227-7-frederic@kernel.org \
--to=frederic@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@kernel.org \
--cc=mingo@redhat.com \
--cc=mtosatti@redhat.com \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=vbabka@suse.cz \
--cc=vschneid@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox