linux-kernel - Re: [RFC PATCH 0/4] CXL Hotness Monitoring Unit perf driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20241122200803.59369-1-sj@kernel.org>
Date: Fri, 22 Nov 2024 12:08:03 -0800
From: SeongJae Park <sj@...nel.org>
To: Jonathan Cameron <Jonathan.Cameron@...wei.com>
Cc: SeongJae Park <sj@...nel.org>,
	Gregory Price <gourry@...rry.net>,
	linux-cxl@...r.kernel.org,
	linux-mm@...ck.org,
	linux-perf-users@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linuxarm@...wei.com,
	tongtiangen@...wei.com,
	Yicong Yang <yangyicong@...wei.com>,
	Niyas Sait <niyas.sait@...wei.com>,
	ajayjoshi@...ron.com,
	Vandana Salve <vsalve@...ron.com>,
	Davidlohr Bueso <dave@...olabs.net>,
	Dave Jiang <dave.jiang@...el.com>,
	Alison Schofield <alison.schofield@...el.com>,
	Ira Weiny <ira.weiny@...el.com>,
	Dan Williams <dan.j.williams@...el.com>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	"Arnaldo Carvalho de Melo" <acme@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Huang Ying <ying.huang@...el.com>
Subject: Re: [RFC PATCH 0/4] CXL Hotness Monitoring Unit perf driver

On Thu, 21 Nov 2024 14:58:52 +0000 Jonathan Cameron <Jonathan.Cameron@...wei.com> wrote:

> On Thu, 21 Nov 2024 09:24:43 -0500
> Gregory Price <gourry@...rry.net> wrote:
> 
> > On Thu, Nov 21, 2024 at 10:18:41AM +0000, Jonathan Cameron wrote:
[...]
> Just working out how to tune the hardware to grab useful data is going
> to take a while to figure out, let alone doing anything much with it.
> 
> Without care you won't get a meaningful signal for what is actually
> hot out of the box. Lots of reasons why including:
> a) Exhaustion of tracking resources, due to looking at too large a window
>    or for too long.  Will probably need some form of auto updating of
>    what is being scanning (coarse to fine might work though I'm doubtful,
>    scanning across small regions maybe).
> b) Threshold too high, no detections.
> c) Threshold too low, everything hot.
> d) Wrong timescales. Hot is not a well defined thing.
> e) Hardware that won't do tracking at fine enough granularity.

Similar questions can be raised to general hotness monitoring including that
for DAMON.  I'm trying to summarize[1] rules of thumbs for DAMON tuning based
on my humble experiences.  Once it is done, I will further try automations of
tunings.

In future, hopefully DAMON can be extended to utilize CXL hotness monitoring
unit as low level primitive for access check.  Then, the guidance and
automation of DAMON tuning could be just applied.

Note that I'm not saying DAMON should be the only way to utilize CXL hotness
monitoring unit.  I'm saying DAMON could be one of the ways :)

[1] https://lore.kernel.org/20241108232536.73843-1-sj@kernel.org


Thanks,
SJ

[...]