From: Peter Zijlstra <peterz@infradead.org>
To: "Chen, Yu C" <yu.c.chen@intel.com>
Cc: Michal Hocko <mhocko@suse.com>, Ingo Molnar <mingo@redhat.com>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Tim Chen <tim.c.chen@intel.com>,
linux-kernel@vger.kernel.org, Jirka Hladky <jhladky@redhat.com>,
Srikanth Aithal <Srikanth.Aithal@amd.com>,
Suneeth D <Suneeth.D@amd.com>, Libo Chen <libo.chen@oracle.com>
Subject: Re: [PATCH] sched/numa: Fix NULL pointer access to mm_struct durng task swap
Date: Thu, 3 Jul 2025 16:01:09 +0200 [thread overview]
Message-ID: <20250703140109.GW1613376@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <b96a326c-7ca7-4cfe-96e2-28c1dad5c9dc@intel.com>
On Thu, Jul 03, 2025 at 09:38:08PM +0800, Chen, Yu C wrote:
> Hi Peter,
>
> On 7/3/2025 8:36 PM, Peter Zijlstra wrote:
> > On Thu, Jul 03, 2025 at 05:20:47AM -0700, Libo Chen wrote:
> >
> > > I agree. The other parts, schedstat and vmstat, are still quite helpful.
> > > Also tracepoints are more expensive than counters once enabled, I think
> > > that's too much for just counting numbers.
> >
> > I'm not generally a fan of eBPF, but supposedly it is really good for
> > stuff like this.
> >
> > Attaching to a tracepoint and distributing into cgroup buckets seems
> > like it should be a trivial script.
>
> Yes, it is feasible to use eBPF. On the other hand, if some
> existing monitoring programs rely on /proc/{pid}/sched to observe
> the NUMA balancing metrics of processes, it might be helpful to
> include the NUMA migration/swap information in /proc/{pid}/sched.
> This approach can minimize the modifications needed for these
> monitoring programs, eliminating the need to add a new BPF script
> to obtain NUMA balancing statistics from different sources IMHO.
Maybe...
The thing is, most of the time the effort spend on collecting all these
numbers is wasted energy since nobody ever looks at them.
Sometimes we're stuck with ABI, like the proc files you mentioned. We
can't readily remove them, stuff would break. But does that mean we
should endlessly add to them just because convenient?
Ideally I would strip out all the statistics and accounting crap and
make sure we have tracepoints (not trace-events) covering all the needed
spots, and then maybe just maybe have a few kernel modules that hook
into those tracepoints to provide the legacy interfaces.
That way, only the people that care get to pay the overhead of actually
collecting the numbers.
One can dream I suppose... :-)
next prev parent reply other threads:[~2025-07-03 14:01 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-02 16:32 Chen Yu
2025-07-02 21:08 ` Andrew Morton
2025-07-03 9:24 ` Chen, Yu C
2025-07-03 7:18 ` Michal Hocko
2025-07-03 9:37 ` Chen, Yu C
2025-07-03 11:51 ` Michal Hocko
2025-07-03 11:55 ` Peter Zijlstra
2025-07-03 7:26 ` Peter Zijlstra
2025-07-03 9:28 ` Michal Hocko
2025-07-03 11:50 ` Peter Zijlstra
2025-07-03 12:01 ` Michal Hocko
2025-07-03 12:04 ` Chen, Yu C
2025-07-03 12:20 ` Libo Chen
2025-07-03 12:36 ` Peter Zijlstra
2025-07-03 13:38 ` Chen, Yu C
2025-07-03 14:01 ` Peter Zijlstra [this message]
2025-07-04 5:57 ` Chen, Yu C
2025-07-03 13:57 ` Libo Chen
2025-07-03 14:18 ` Peter Zijlstra
2025-07-03 23:35 ` Libo Chen
2025-07-04 8:26 ` Peter Zijlstra
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=20250703140109.GW1613376@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=Srikanth.Aithal@amd.com \
--cc=Suneeth.D@amd.com \
--cc=akpm@linux-foundation.org \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=jhladky@redhat.com \
--cc=juri.lelli@redhat.com \
--cc=libo.chen@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=tim.c.chen@intel.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=yu.c.chen@intel.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®