Date: Mon, 20 May 2024 12:58:57 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Shiju Jose <shiju.jose@...wei.com>
CC: Borislav Petkov <bp@...en8.de>, Dan Williams <dan.j.williams@...el.com>,
	"linux-cxl@...r.kernel.org" <linux-cxl@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>, "dave@...olabs.net"
	<dave@...olabs.net>, "dave.jiang@...el.com" <dave.jiang@...el.com>,
	"alison.schofield@...el.com" <alison.schofield@...el.com>,
	"vishal.l.verma@...el.com" <vishal.l.verma@...el.com>, "ira.weiny@...el.com"
	<ira.weiny@...el.com>, "linux-edac@...r.kernel.org"
	<linux-edac@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "david@...hat.com" <david@...hat.com>,
	"Vilas.Sridharan@....com" <Vilas.Sridharan@....com>, "leo.duran@....com"
	<leo.duran@....com>, "Yazen.Ghannam@....com" <Yazen.Ghannam@....com>,
	"rientjes@...gle.com" <rientjes@...gle.com>, "jiaqiyan@...gle.com"
	<jiaqiyan@...gle.com>, "tony.luck@...el.com" <tony.luck@...el.com>,
	"Jon.Grimm@....com" <Jon.Grimm@....com>, "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>, "rafael@...nel.org" <rafael@...nel.org>,
	"lenb@...nel.org" <lenb@...nel.org>, "naoya.horiguchi@....com"
	<naoya.horiguchi@....com>, "james.morse@....com" <james.morse@....com>,
	"jthoughton@...gle.com" <jthoughton@...gle.com>, "somasundaram.a@....com"
	<somasundaram.a@....com>, "erdemaktas@...gle.com" <erdemaktas@...gle.com>,
	"pgonda@...gle.com" <pgonda@...gle.com>, "duenwen@...gle.com"
	<duenwen@...gle.com>, "mike.malvestuto@...el.com"
	<mike.malvestuto@...el.com>, "gthelen@...gle.com" <gthelen@...gle.com>,
	"wschwartz@...erecomputing.com" <wschwartz@...erecomputing.com>,
	"dferguson@...erecomputing.com" <dferguson@...erecomputing.com>,
	"wbs@...amperecomputing.com" <wbs@...amperecomputing.com>,
	"nifan.cxl@...il.com" <nifan.cxl@...il.com>, tanxiaofei
	<tanxiaofei@...wei.com>, "Zengtao (B)" <prime.zeng@...ilicon.com>,
	"kangkang.shen@...urewei.com" <kangkang.shen@...urewei.com>, wanghuiqiang
	<wanghuiqiang@...wei.com>, Linuxarm <linuxarm@...wei.com>, "Greg
 Kroah-Hartman" <gregkh@...uxfoundation.org>, Jean Delvare
	<jdelvare@...e.com>, Guenter Roeck <linux@...ck-us.net>, Dmitry Torokhov
	<dmitry.torokhov@...il.com>
Subject: Re: [RFC PATCH v8 01/10] ras: scrub: Add scrub subsystem

On Mon, 20 May 2024 11:54:50 +0100
Shiju Jose <shiju.jose@...wei.com> wrote:

> >-----Original Message-----
> >From: Borislav Petkov <bp@...en8.de>
> >Sent: 11 May 2024 11:17
> >To: Dan Williams <dan.j.williams@...el.com>
> >Cc: Jonathan Cameron <jonathan.cameron@...wei.com>; Shiju Jose
> ><shiju.jose@...wei.com>; linux-cxl@...r.kernel.org; linux-
> >acpi@...r.kernel.org; linux-mm@...ck.org; dave@...olabs.net;
> >dave.jiang@...el.com; alison.schofield@...el.com; vishal.l.verma@...el.com;
> >ira.weiny@...el.com; linux-edac@...r.kernel.org; linux-
> >kernel@...r.kernel.org; david@...hat.com; Vilas.Sridharan@....com;
> >leo.duran@....com; Yazen.Ghannam@....com; rientjes@...gle.com;
> >jiaqiyan@...gle.com; tony.luck@...el.com; Jon.Grimm@....com;
> >dave.hansen@...ux.intel.com; rafael@...nel.org; lenb@...nel.org;
> >naoya.horiguchi@....com; james.morse@....com; jthoughton@...gle.com;
> >somasundaram.a@....com; erdemaktas@...gle.com; pgonda@...gle.com;
> >duenwen@...gle.com; mike.malvestuto@...el.com; gthelen@...gle.com;
> >wschwartz@...erecomputing.com; dferguson@...erecomputing.com;
> >wbs@...amperecomputing.com; nifan.cxl@...il.com; tanxiaofei
> ><tanxiaofei@...wei.com>; Zengtao (B) <prime.zeng@...ilicon.com>;
> >kangkang.shen@...urewei.com; wanghuiqiang <wanghuiqiang@...wei.com>;
> >Linuxarm <linuxarm@...wei.com>; Greg Kroah-Hartman
> ><gregkh@...uxfoundation.org>; Jean Delvare <jdelvare@...e.com>; Guenter
> >Roeck <linux@...ck-us.net>; Dmitry Torokhov <dmitry.torokhov@...il.com>
> >Subject: Re: [RFC PATCH v8 01/10] ras: scrub: Add scrub subsystem
> >
> >On Fri, May 10, 2024 at 10:13:41AM -0700, Dan Williams wrote:  
> >> In fact this question matches my reaction to the last posting [1], and
> >> led to a much improved cover letter and the "Comparison of scrubbing
> >> features". To your point there are scrub capabilities already in the
> >> kernel and we would need to make a decision about what to do about them.  
> >
> >The answer to that question is whether this new userspace usage is going to
> >want to control those too.
> >
> >So
> >
> >"Use case of scrub control feature"
> >
> >from the cover letter is giving two short sentences about what one would do but
> >I'm still meh. A whole subsystem needing a bunch of effort would need a lot
> >more justification.
> >
> >So can anyone please elaborate more on the use cases and why this new thing is
> >needed?  
> 
> Following are some of the use cases of generic scrub control subsystem as given in the cover letter.
> Request please add any other use cases, which I missed.
> 
> 1. There are several types of interfaces to HW memory scrubbers identified such as ACPI NVDIMM ARS(Address Range Scrub), CXL memory device patrol scrub, CXL DDR5 ECS, ACPI RAS2 memory scrubbing features and software based memory scrubber(discussed in the community Reference [5] in the cover letter). Also some scrubbers support controlling (background) patrol scrubbing(ACPI RAS2, CXL)  and/or on-demand scrubbing(ACPI RAS2, ACPI ARS).  However the scrub controls varies between memory scrubbers. Thus there is  a need  for a standard generic ABI and sysfs scrub controls for the userspace tools, which control HW and SW scrubbers in the system, for the easiness of use.
> 2. Scrub controls in user space allow the user space tool to disable and enable the feature in case disabling of the background patrol  scrubbing and changing the scrub rate are needed for other purposes such as performance-aware operations which requires the background operations to be turned off or reduced.
> 3. Allows to perform on-demand scrubbing for specific address range if supported by the scrubber.
> 4. User space tools controls scrub the memory DIMMs regularly at a configurable scrub rate using the sysfs scrub controls discussed help, 
>     - to detect uncorrectable memory errors early before user accessing memory, which helps to recover the detected memory errors.
>     -  reduces the chance of a correctable error becoming uncorrectable.

Just to add one more reason a user space interface is needed.
5. Policy control for hotplugged memory.  There is not necessarily a system wide bios
   or similar in the loop to control the scrub settings on a CXL device that wasn't
   there at boot.  What that setting should be is a policy decision as we are trading
   of reliability vs performance - hence it should be in control of userspace.
   As such, 'an' interface is needed. Seems more sensible to try and unify it with
   other similar interfaces than spin yet another one.

> 
> Regards,
> Shiju
> 

Powered by blists - more mailing lists