From: Tony Luck <tony.luck@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Fenghua Yu <fenghua.yu@intel.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
patches@lists.linux.dev, Tony Luck <tony.luck@intel.com>
Subject: [PATCH v2 0/2] Make life miserable for split lockers
Date: Thu, 10 Mar 2022 12:48:52 -0800 [thread overview]
Message-ID: <20220310204854.31752-1-tony.luck@intel.com> (raw)
In-Reply-To: <20220217012721.9694-1-tony.luck@intel.com>
See part 0001 commit message for what & why.
Changes since v1(RFC) based on feedback from Thomas:
1) No longer implemented as new sub-option of split_lock_detect boot
option. Just update the existing (default) "warn" mode.
2) Use the (more appropriate) "schedule_delayed_work_on() instead of
schedule_delayed_work() to re-enable split lock detection.
3) Add msleep for extra misery before disabling split lock detection
on a core.
Next two aren't from Thomas.
4) Drop the TIF_SLD bit and associated code. No longer needed. This
part is done as clean up in patch 0002.
5) Add a bit in task structure to make sure each split-locking task
only tries to print a warn message to the console once. Need this
to preserve existing behavior that was previously controlled by the
TIF_SLD bit.
Testing notes. I checked this out by running 2,000 processes that
each looped executing 10,000 split locks. System remains very
responsive while this test is running (compared with unusable
without these patches). When each process gets the semaphore
and two jiffies of time to execute split locks it manages to
complete ~430 before the delayed work thread re-enables detection.
The semaphore gives nice round-robin access to the 2,000 tasks.
So each ends up blocking for 24ish seconds while the other 1,999
task take their turn.
Tony Luck (2):
x86/split_lock: Make life miserable for split lockers
x86/split-lock: Remove unused TIF_SLD bit
arch/x86/include/asm/cpu.h | 2 -
arch/x86/include/asm/thread_info.h | 4 +-
arch/x86/kernel/cpu/intel.c | 77 +++++++++++++++++++++---------
arch/x86/kernel/process.c | 3 --
include/linux/sched.h | 3 ++
kernel/fork.c | 5 ++
6 files changed, 64 insertions(+), 30 deletions(-)
--
2.35.1
next prev parent reply other threads:[~2022-03-10 20:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-17 1:27 [PATCH] x86/split_lock: " Tony Luck
2022-03-07 22:30 ` Thomas Gleixner
2022-03-08 0:37 ` Luck, Tony
2022-03-08 14:59 ` Thomas Gleixner
2022-03-08 17:12 ` Luck, Tony
2022-03-10 20:48 ` Tony Luck [this message]
2022-03-10 20:48 ` [PATCH v2 1/2] " Tony Luck
2022-03-17 11:13 ` Pavel Machek
2022-03-17 16:27 ` Luck, Tony
2022-03-17 18:06 ` Thomas Gleixner
2022-03-17 22:21 ` David Laight
2022-03-17 22:40 ` Luck, Tony
2022-03-18 12:21 ` Fenghua Yu
2022-04-27 13:49 ` [tip: x86/splitlock] " tip-bot2 for Tony Luck
2022-03-10 20:48 ` [PATCH v2 2/2] x86/split-lock: Remove unused TIF_SLD bit Tony Luck
2022-04-27 13:49 ` [tip: x86/splitlock] " tip-bot2 for Tony Luck
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=20220310204854.31752-1-tony.luck@intel.com \
--to=tony.luck@intel.com \
--cc=fenghua.yu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@lists.linux.dev \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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®