From: Leonardo Bras <leobras@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>,
Marcelo Tosatti <mtosatti@redhat.com>,
linux-kernel@vger.kernel.org
Cc: Leonardo Bras <leobras@redhat.com>
Subject: [RFC PATCH 2/4] swap: apply new local_schedule_work_on() interface
Date: Sat, 29 Jul 2023 05:37:33 -0300 [thread overview]
Message-ID: <20230729083737.38699-4-leobras@redhat.com> (raw)
In-Reply-To: <20230729083737.38699-2-leobras@redhat.com>
Make use of the new local_*lock_n*() and local_schedule_work_on() interface
to improve performance & latency on PREEMTP_RT kernels.
For functions that may be scheduled in a different cpu, replace
local_*lock*() by local_lock_n*(), and replace schedule_work_on() by
local_schedule_work_on(). The same happens for flush_work() and
local_flush_work().
This should bring no relevant performance impact on non-RT kernels:
For functions that may be scheduled in a different cpu, the local_*lock's
this_cpu_ptr() becomes a per_cpu_ptr(smp_processor_id()).
Signed-off-by: Leonardo Bras <leobras@redhat.com>
---
mm/swap.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/mm/swap.c b/mm/swap.c
index cd8f0150ba3a..a79f2091eae5 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -760,11 +760,11 @@ 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)
+static void lru_add_and_bh_lrus_drain(int cpu)
{
- local_lock(&cpu_fbatches.lock);
- lru_add_drain_cpu(smp_processor_id());
- local_unlock(&cpu_fbatches.lock);
+ local_lock_n(&cpu_fbatches.lock, cpu);
+ lru_add_drain_cpu(cpu);
+ local_unlock_n(&cpu_fbatches.lock, cpu);
invalidate_bh_lrus_cpu();
mlock_drain_local();
}
@@ -782,9 +782,9 @@ void lru_add_drain_cpu_zone(struct zone *zone)
static DEFINE_PER_CPU(struct work_struct, lru_add_drain_work);
-static void lru_add_drain_per_cpu(struct work_struct *dummy)
+static void lru_add_drain_per_cpu(struct work_struct *w)
{
- lru_add_and_bh_lrus_drain();
+ lru_add_and_bh_lrus_drain(w->data.counter);
}
static bool cpu_needs_drain(unsigned int cpu)
@@ -888,13 +888,13 @@ static inline void __lru_add_drain_all(bool force_all_cpus)
if (cpu_needs_drain(cpu)) {
INIT_WORK(work, lru_add_drain_per_cpu);
- queue_work_on(cpu, mm_percpu_wq, work);
+ local_queue_work_on(cpu, mm_percpu_wq, work);
__cpumask_set_cpu(cpu, &has_work);
}
}
for_each_cpu(cpu, &has_work)
- flush_work(&per_cpu(lru_add_drain_work, cpu));
+ local_flush_work(&per_cpu(lru_add_drain_work, cpu));
done:
mutex_unlock(&lock);
@@ -941,7 +941,7 @@ void lru_cache_disable(void)
#ifdef CONFIG_SMP
__lru_add_drain_all(true);
#else
- lru_add_and_bh_lrus_drain();
+ lru_add_and_bh_lrus_drain(smp_processor_id());
#endif
}
--
2.41.0
next prev parent reply other threads:[~2023-07-29 8:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-29 8:37 [RFC PATCH 0/4] Improve RT performance & latency w/ local_lock_t() Leonardo Bras
2023-07-29 8:37 ` [RFC PATCH 1/4] Introducing local_lock_n() and local queue & flush Leonardo Bras
2023-07-29 8:37 ` Leonardo Bras [this message]
2023-08-08 19:39 ` [RFC PATCH 2/4] swap: apply new local_schedule_work_on() interface Marcelo Tosatti
2023-08-29 0:07 ` Leonardo Brás
2023-07-29 8:37 ` [RFC PATCH 3/4] memcontrol: " Leonardo Bras
2023-07-29 8:37 ` [RFC PATCH 4/4] slub: " Leonardo Bras
2023-08-01 19:05 ` [RFC PATCH 0/4] Improve RT performance & latency w/ local_lock_t() Leonardo Bras Soares Passos
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=20230729083737.38699-4-leobras@redhat.com \
--to=leobras@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=tglx@linutronix.de \
/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