From: Peter Zijlstra <peterz@infradead.org>
To: Aaron Lu <aaron.lu@intel.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
linux-kernel@vger.kernel.org, Olivier Dion <odion@efficios.com>,
michael.christie@oracle.com
Subject: Re: [RFC PATCH v4] sched: Fix performance regression introduced by mm_cid
Date: Thu, 13 Apr 2023 13:10:47 +0200 [thread overview]
Message-ID: <20230413111047.GB83892@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20230412143934.GB162902@ziqianlu-desk2>
On Wed, Apr 12, 2023 at 10:39:34PM +0800, Aaron Lu wrote:
> On Wed, Apr 12, 2023 at 04:26:16PM +0200, Peter Zijlstra wrote:
> > On Wed, Apr 12, 2023 at 07:42:40PM +0800, Aaron Lu wrote:
> >
> > > I *guess* you might be able to see some contention with hackbench on
> > > that HSW-EX system with v4.
> >
> > Indeed! Notably it seems to be the wakeup from idle that trips it
> > hardest:
>
> Could it because for idle cpus, the per-cpu/mm cid is no longer valid for
> the sake of compacting and when task wakes there, it will have to
> re-allocate a new cid through mm_get_cid() which needs to acquire
> mm->cid_lock?
Yup. And I'm thinking it is futile (and counter productive) to strive
for compactness in this (nr_threads >= nr_cpus) case.
The below on v4 solves the contention I see with hackbench (which runs
400 threads which is well above the 144 cpu count on that machine).
This obviously leaves a problem with the nr_threads = nr_cpus - 1 case,
but I'm thinking we can add some fuzz (nr_cpu_ids - ilog2(nr_cpus_ids+1)
perhaps). Also, I would be thinking that's not something that typically
happens.
Mathieu, WDYT? -- other than that the patch is an obvious hack :-)
---
include/linux/mm_types.h | 8 ++++++++
kernel/fork.c | 4 +++-
kernel/sched/core.c | 9 +++++++++
kernel/sched/sched.h | 2 ++
4 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 4160ff5c6ebd..598d1b657afa 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -609,6 +609,7 @@ struct mm_struct {
* were being concurrently updated by the updaters.
*/
raw_spinlock_t cid_lock;
+ int cid_saturated;
/**
* @pcpu_cid: Per-cpu current cid.
*
@@ -912,6 +913,12 @@ static inline int mm_cid_clear_lazy_put(int cid)
return cid & ~MM_CID_LAZY_PUT;
}
+static inline void mm_cid_desaturate(struct mm_struct *mm)
+{
+ if (mm->cid_saturated && atomic_read(&mm->mm_users) < nr_cpu_ids)
+ mm->cid_saturated = 0;
+}
+
/* Accessor for struct mm_struct's cidmask. */
static inline cpumask_t *mm_cidmask(struct mm_struct *mm)
{
@@ -928,6 +935,7 @@ static inline void mm_init_cid(struct mm_struct *mm)
int i;
raw_spin_lock_init(&mm->cid_lock);
+ mm->cid_saturated = 0;
for_each_possible_cpu(i)
*per_cpu_ptr(mm->pcpu_cid, i) = MM_CID_UNSET;
cpumask_clear(mm_cidmask(mm));
diff --git a/kernel/fork.c b/kernel/fork.c
index 3832bea713c4..a5233e450435 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1233,7 +1233,9 @@ void mmput(struct mm_struct *mm)
might_sleep();
if (atomic_dec_and_test(&mm->mm_users))
- __mmput(mm);
+ return __mmput(mm);
+
+ mm_cid_desaturate(mm);
}
EXPORT_SYMBOL_GPL(mmput);
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 425766cc1300..d5004d179531 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -11550,6 +11550,15 @@ void sched_mm_cid_migrate_from(struct task_struct *t)
if (last_mm_cid == -1)
return;
+ /*
+ * When nr_threads > nr_cpus, there is no point in moving anything
+ * around to keep it compact.
+ */
+ if (mm->cid_saturated) {
+ t->last_mm_cid = -1;
+ return;
+ }
+
src_rq = task_rq(t);
src_pcpu_cid = per_cpu_ptr(mm->pcpu_cid, cpu_of(src_rq));
src_cid = READ_ONCE(*src_pcpu_cid);
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index f3e7dc2cd1cc..6c4af2992e79 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -3347,6 +3347,8 @@ static inline int mm_cid_get(struct mm_struct *mm)
}
raw_spin_lock(&mm->cid_lock);
cid = __mm_cid_get_locked(mm);
+ if (cid == nr_cpu_ids - 1)
+ mm->cid_saturated = 1;
raw_spin_unlock(&mm->cid_lock);
WRITE_ONCE(*pcpu_cid, cid);
return cid;
next prev parent reply other threads:[~2023-04-13 11:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-10 15:01 Mathieu Desnoyers
2023-04-10 21:51 ` michael.christie
2023-04-11 4:52 ` Aaron Lu
2023-04-11 13:12 ` Aaron Lu
2023-04-12 9:10 ` Peter Zijlstra
2023-04-12 11:42 ` Aaron Lu
2023-04-12 14:26 ` Peter Zijlstra
2023-04-12 14:39 ` Aaron Lu
2023-04-13 11:10 ` Peter Zijlstra [this message]
2023-04-13 13:49 ` Aaron Lu
2023-04-13 13:56 ` Mathieu Desnoyers
2023-04-13 15:20 ` Peter Zijlstra
2023-04-13 15:37 ` Mathieu Desnoyers
2023-04-12 4:27 ` Aaron Lu
2023-04-12 20:57 ` Mathieu Desnoyers
2023-04-13 13:13 ` Aaron Lu
2023-04-13 13:38 ` Mathieu Desnoyers
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=20230413111047.GB83892@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=aaron.lu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=michael.christie@oracle.com \
--cc=odion@efficios.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
all inboxes | Powered by JetHome®