All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cristian Prundeanu <cpru@amazon.com>
To: K Prateek Nayak <kprateek.nayak@amd.com>
Cc: Cristian Prundeanu <cpru@amazon.com>,
	Hazem Mohamed Abuelfotoh <abuehaze@amazon.com>,
	Ali Saidi <alisaidi@amazon.com>,
	"Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
	Geoff Blake <blakgeof@amazon.com>,
	Csaba Csoma <csabac@amazon.com>,
	Bjoern Doebel <doebel@amazon.com>,
	"Gautham Shenoy" <gautham.shenoy@amd.com>,
	Joseph Salisbury <joseph.salisbury@oracle.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	Borislav Petkov <bp@alien8.de>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-tip-commits@vger.kernel.org>, <x86@kernel.org>
Subject: Re: [PATCH 0/2] [tip: sched/core] sched: Disable PLACE_LAG and RUN_TO_PARITY and move them to sysctl
Date: Tue, 11 Feb 2025 23:41:13 -0600	[thread overview]
Message-ID: <20250212054113.19938-1-cpru@amazon.com> (raw)
In-Reply-To: <feb31b6e-6457-454c-a4f3-ce8ad96bf8de@amd.com>

Hi Prateek,

Thank you for the analysis details!

> Thank you for the reproducer. I haven't tried it yet (in part due
> to the slightly scary "Assumptions" section)

It wasn't meant to be scary, my apologies. It is meant to say that the 
reproducer will only perform testing-related tasks (which you'd normally 
do manually), without touching the infrastructure (firewall, networking, 
instance mangement, etc). As long as you set all that up the same way you 
do when you test manually, you will be fine. I'll clarify the README.

Should you run into any questions, please do not hesitate to contact me 
directly, and I'll help clear the path.

> v6.14-rc1                   baseline
> v6.5.0 (pre-EEVDF)          -0.95%
> v6.14-rc1 + NO_PL + NO_RTP  +6.06%

This is interesting. While you do reproduce the benefits of NO_PL+NO_RTP, 
your result shows no regression compared to the baseline CFS. I'm only 
speculating, but running both SUT and loadgen on the same machine is a 
large variation of the test setup, and can lead to result differences like 
this one.

> Digging through the scripts, I found that SCHED_BATCH setting is done
> via systemd in [3] via the "CPUSchedulingPolicy" parameter.
> [3] https://github.com/aws/repro-collection/blob/main/workloads/mysql/files/mysqld.service.tmpl

That is correct, the reproducer uses systemd to set the scheduler policy 
for mysqld.

> interestingly, if I do (version 1): [...]
> I more or less get the same results as baseline v6.14-rc1 (Weird!)
> But then if I do (version 2): [...]
> I see the performance reach to the same level as that with NO_PL +
> NO_RTP.

That's a good find. I will compare on my setup if performance changes when 
manually setting all mysqld tasks to SCHED_BATCH. And I haven't yet run 
perf sched stats on the reproducer, but it may hold useful insight. 
I'll follow up with more details as I gather them.

Your find also helps to point out that even when it works, SCHED_BATCH is 
a more complex and error prone mitigation than just disabling PL and RTP. 
The same reproducer setup that uses systemd to set SCHED_BATCH does show 
improvement in 6.12, but not in 6.13+. There may not even be a single 
approach that works well on both.

Conversely, setting NO_PLACE_LAG + NO_RUN_TO_PARITY is simply done at boot 
time, and does not require further user effort. It's even simpler if those 
two features are exposed via sysctl, making it trivial to pesist and query 
with standard Linux commands as needed. 

Peter, I've renewed my initial patch so it applies to the current 
sched/core, and removed the dependency on changing the default values 
first. I'd appreciate you considering it for merging [1].

[1] https://lore.kernel.org/20250212053644.14787-1-cpru@amazon.com

-Cristian


  reply	other threads:[~2025-02-12  5:43 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-19 11:04 [GIT PULL] sched/urgent for v6.13 Borislav Petkov
2025-01-19 17:54 ` pr-tracker-bot
2025-01-28 23:09 ` [PATCH 0/2] [tip: sched/core] sched: Disable PLACE_LAG and RUN_TO_PARITY and move them to sysctl Cristian Prundeanu
2025-02-11  3:27   ` K Prateek Nayak
2025-02-12  5:41     ` Cristian Prundeanu [this message]
2025-02-12  9:43       ` Peter Zijlstra
2025-02-12  5:36   ` [PATCH v2] [tip: sched/core] sched: Move PLACE_LAG and RUN_TO_PARITY " Cristian Prundeanu
2025-02-12  9:17     ` Peter Zijlstra
2025-02-12  9:37       ` Peter Zijlstra
2025-02-12 23:00         ` Cristian Prundeanu
  -- strict thread matches above, loose matches on Subject: below --
2024-10-19  2:30 [PATCH 0/2] [tip: sched/core] sched: Disable PLACE_LAG and RUN_TO_PARITY and move them " Prundeanu, Cristian
2024-10-24  8:12 ` Benjamin Herrenschmidt
2024-10-25 14:43   ` Gautham R. Shenoy
2024-10-29  4:57     ` Cristian Prundeanu
2024-10-30 10:21       ` Dietmar Eggemann
2024-11-01 13:05       ` Peter Zijlstra
2024-11-04 10:19       ` Gautham R. Shenoy
2024-11-04 10:34         ` K Prateek Nayak
2024-10-17  5:19 Cristian Prundeanu
2024-10-17  9:10 ` Peter Zijlstra
2024-10-17 18:19   ` Prundeanu, Cristian
2024-10-18  7:07     ` K Prateek Nayak
2024-10-18  9:54     ` Mohamed Abuelfotoh, Hazem
2024-11-14 20:10 ` Joseph Salisbury
2024-11-19 10:29   ` Dietmar Eggemann
2024-11-25 11:35 ` Cristian Prundeanu
2024-11-26  3:58   ` K Prateek Nayak
2024-11-26 15:12   ` Dietmar Eggemann
2024-11-28 10:32   ` Cristian Prundeanu
2024-11-29 10:12     ` Dietmar Eggemann

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=20250212054113.19938-1-cpru@amazon.com \
    --to=cpru@amazon.com \
    --cc=abuehaze@amazon.com \
    --cc=alisaidi@amazon.com \
    --cc=benh@kernel.crashing.org \
    --cc=blakgeof@amazon.com \
    --cc=bp@alien8.de \
    --cc=csabac@amazon.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=doebel@amazon.com \
    --cc=gautham.shenoy@amd.com \
    --cc=joseph.salisbury@oracle.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.