From: Chen Yu <yu.c.chen@intel.com>
To: Jemmy Wong <jemmywong512@gmail.com>
Cc: <mingo@redhat.com>, <peterz@infradead.org>,
<tim.c.chen@linux.intel.com>, <chen.yu@linux.dev>,
<juri.lelli@redhat.com>, <vincent.guittot@linaro.org>,
<dietmar.eggemann@arm.com>, <rostedt@goodmis.org>,
<bsegall@google.com>, <mgorman@suse.de>, <vschneid@redhat.com>,
<kprateek.nayak@amd.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3] sched/cache: Remove the old cache group footprint on exec
Date: Wed, 21 Oct 2026 18:12:01 +0800 [thread overview]
Message-ID: <atiP8TwaDDtbImRn@chenyu-dev> (raw)
In-Reply-To: <20261015053604.29927-1-jemmywong512@gmail.com>
On Thu, Oct 15, 2026 at 01:36:04PM +0800, Jemmy Wong wrote:
[ ... ]
> @@ -3965,36 +3974,6 @@ static void task_numa_placement(struct task_struct *p)
> ng->total_faults += diff;
> group_faults += ng->faults[mem_idx];
> }
> -#ifdef CONFIG_SCHED_CACHE
> - /*
> - * Per task p->numa_faults[mem_idx] converges,
> - * so the accumulation of each task's faults
> - * converges too - Given the number of threads,
> - * it cannot overflow an unsigned long.
Above comments can be kept for future reference, with minor adjustment:
s/it cannot overflow an unsigned long/it cannot overflow an atomic_long_t
I launched a full hackbench test on a Xeon with multiple LLCs per node. There
is no obvious difference except for some false-positive regress with large
run-to-run variance. This patch looks good to me in terms of turning the
footprint into an accurate counter. Feel free to add:
Reviewed-by: Chen Yu <yu.c.chen@intel.com>
Tested-by: Chen Yu <yu.c.chen@intel.com>
thanks,
Chenyu
First run:
=========================================
Hackbench comparison
BASE: cas_on_baseline
TEST: cas_on_patched
=========================================
MODE G FD | BASE(s) | TEST(s) | DIFF% | RESULT
------- -- ----+-----------------+-----------------+---------+----------
process 16 1 | 0.178/1.7% | 0.166/0.6% | 6.74% | IMPROVED
process 16 16 | 4.871/9.1% | 5.230/3.8% | -7.37% | REGRESSED
process 16 2 | 1.574/3.0% | 1.296/27.5% | 17.66% | IMPROVED
process 16 20 | 6.502/7.8% | 6.262/1.5% | 3.69% | IMPROVED
process 16 4 | 2.296/5.0% | 2.138/13.0% | 6.88% | IMPROVED
process 16 8 | 2.056/1.1% | 1.982/12.3% | 3.60% | IMPROVED
process 1 1 | 2.040/0.8% | 2.010/4.5% | 1.47% | IMPROVED
process 1 16 | 4.837/3.5% | 4.189/12.7% | 13.40% | IMPROVED
process 1 2 | 3.708/5.0% | 2.768/14.3% | 25.35% | IMPROVED
process 1 20 | 4.552/3.5% | 4.505/2.2% | 1.03% | IMPROVED
process 1 4 | 2.696/17.0% | 3.092/21.8% | -14.69% | REGRESSED
process 1 8 | 5.474/3.4% | 5.372/9.3% | 1.86% | IMPROVED
process 2 1 | 1.089/3.4% | 1.115/2.3% | -2.39% | REGRESSED
process 2 16 | 4.985/13.9% | 5.246/5.1% | -5.24% | REGRESSED
process 2 2 | 1.063/7.2% | 0.998/3.2% | 6.11% | IMPROVED
process 2 20 | 5.091/13.6% | 5.081/3.1% | 0.20% | IMPROVED
process 2 4 | 3.935/18.2% | 3.438/23.2% | 12.63% | IMPROVED
process 2 8 | 4.791/7.0% | 4.925/3.8% | -2.80% | REGRESSED
process 4 1 | 0.690/18.3% | 0.586/1.9% | 15.07% | IMPROVED
process 4 16 | 5.878/3.5% | 6.119/1.9% | -4.10% | REGRESSED
process 4 2 | 0.534/6.4% | 0.512/2.7% | 4.12% | IMPROVED
process 4 20 | 5.839/3.1% | 5.644/5.0% | 3.34% | IMPROVED
process 4 4 | 4.012/1.5% | 3.386/12.0% | 15.60% | IMPROVED
process 4 8 | 4.737/11.0% | 4.703/3.9% | 0.72% | IMPROVED
process 8 1 | 0.317/0.9% | 0.322/0.3% | -1.58% | REGRESSED
process 8 16 | 3.671/5.4% | 3.922/4.8% | -6.84% | REGRESSED
process 8 2 | 0.921/35.8% | 0.812/36.0% | 11.83% | IMPROVED
process 8 20 | 4.878/6.9% | 4.769/1.8% | 2.23% | IMPROVED
process 8 4 | 2.969/10.2% | 3.500/16.5% | -17.88% | REGRESSED
process 8 8 | 4.698/2.6% | 4.263/4.7% | 9.26% | IMPROVED
threads 16 1 | 0.192/0.5% | 0.189/0.0% | 1.56% | IMPROVED
threads 16 16 | 5.430/4.7% | 5.685/1.2% | -4.70% | REGRESSED
threads 16 2 | 0.362/17.4% | 0.577/29.6% | -59.39% | REGRESSED
threads 16 20 | 6.210/3.6% | 5.523/6.2% | 11.06% | IMPROVED
threads 16 4 | 2.678/11.0% | 3.173/5.6% | -18.48% | REGRESSED
threads 16 8 | 2.347/3.3% | 2.394/8.7% | -2.00% | REGRESSED
threads 1 1 | 2.131/1.5% | 2.260/2.5% | -6.05% | REGRESSED
threads 1 16 | 0.379/2.4% | 0.353/2.5% | 6.86% | IMPROVED
threads 1 2 | 2.050/0.9% | 2.003/0.6% | 2.29% | IMPROVED
threads 1 20 | 0.347/2.6% | 0.324/0.9% | 6.63% | IMPROVED
threads 1 4 | 1.342/1.0% | 1.333/1.1% | 0.67% | IMPROVED
threads 1 8 | 0.730/2.5% | 0.732/1.4% | -0.27% | REGRESSED
threads 2 1 | 1.144/1.2% | 1.167/1.2% | -2.01% | REGRESSED
threads 2 16 | 0.286/1.4% | 0.987/71.3% | -245.10% | REGRESSED
threads 2 2 | 1.035/2.4% | 1.040/0.5% | -0.48% | REGRESSED
threads 2 20 | 1.016/73.2% | 2.038/43.5% | -100.59% | REGRESSED
threads 2 4 | 0.647/0.9% | 0.647/1.2% | 0.00% | SAME
threads 2 8 | 0.338/1.8% | 0.335/1.5% | 0.89% | IMPROVED
threads 4 1 | 0.658/1.4% | 0.614/4.4% | 6.69% | IMPROVED
threads 4 16 | 6.434/1.4% | 6.194/1.5% | 3.73% | IMPROVED
threads 4 2 | 0.522/2.1% | 0.521/1.7% | 0.19% | IMPROVED
threads 4 20 | 5.361/1.4% | 6.060/1.6% | -13.04% | REGRESSED
threads 4 4 | 0.324/1.5% | 0.335/1.8% | -3.40% | REGRESSED
threads 4 8 | 0.946/35.4% | 0.854/61.1% | 9.73% | IMPROVED
threads 8 1 | 0.351/5.7% | 0.364/1.9% | -3.70% | REGRESSED
threads 8 16 | 3.818/4.8% | 4.109/4.9% | -7.62% | REGRESSED
threads 8 2 | 0.294/6.5% | 0.276/1.4% | 6.12% | IMPROVED
threads 8 20 | 4.640/5.2% | 4.788/9.1% | -3.19% | REGRESSED
threads 8 4 | 1.548/57.0% | 0.880/11.0% | 43.15% | IMPROVED
threads 8 8 | 5.028/2.2% | 5.161/2.9% | -2.65% | REGRESSED
Then I pick the following test, which seems to have a big regression with a
large stderr%:
threads 2 16 | 0.286/1.4% | 0.987/71.3% | -245.10% | REGRESSED
threads 2 20 | 1.016/73.2% | 2.038/43.5% | -100.59% | REGRESSED
threads 16 2 | 0.362/17.4% | 0.577/29.6% | -59.39% | REGRESSED
threads 16 4 | 2.678/11.0% | 3.173/5.6% | -18.48% | REGRESSED
The following is the second run:
=========================================
MODE G FD | BASE(s) | TEST(s) | DIFF% | RESULT
------- -- ----+-----------------+-----------------+---------+----------
threads 2 16 | 0.915/29.6% | 1.376/66.1% | -50.38% | REGRESSED
threads 2 20 | 2.154/23.0% | 1.299/50.7% | 39.69% | IMPROVED
threads 16 2 | 0.320/18.8% | 0.756/26.3% | -136.25% | REGRESSED
threads 16 4 | 4.139/1.9% | 3.174/18.2% | 23.31% | IMPROVED
So the data seems to be quite unstable when the system is saturated, which
might be another issue that I'll investigate soon.
next prev parent reply other threads:[~2026-10-21 10:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 5:36 Jemmy Wong
2026-10-21 10:12 ` Chen Yu [this message]
2026-10-21 12:50 ` Jemmy Wong
2026-10-21 16:53 ` Chen Yu
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=atiP8TwaDDtbImRn@chenyu-dev \
--to=yu.c.chen@intel.com \
--cc=bsegall@google.com \
--cc=chen.yu@linux.dev \
--cc=dietmar.eggemann@arm.com \
--cc=jemmywong512@gmail.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tim.c.chen@linux.intel.com \
--cc=vincent.guittot@linaro.org \
--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
all inboxes | Powered by JetHome®