Received-SPF: pass (google.com: domain of linux-kernel+bounces-190308-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Mon, 27 May 2024 11:21:31 +0200
From: Borislav Petkov <bp@alien8.de>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Shiju Jose <shiju.jose@huawei.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
	"linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"dave@stgolabs.net" <dave@stgolabs.net>,
	"dave.jiang@intel.com" <dave.jiang@intel.com>,
	"alison.schofield@intel.com" <alison.schofield@intel.com>,
	"vishal.l.verma@intel.com" <vishal.l.verma@intel.com>,
	"ira.weiny@intel.com" <ira.weiny@intel.com>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"david@redhat.com" <david@redhat.com>,
	"Vilas.Sridharan@amd.com" <Vilas.Sridharan@amd.com>,
	"leo.duran@amd.com" <leo.duran@amd.com>,
	"Yazen.Ghannam@amd.com" <Yazen.Ghannam@amd.com>,
	"rientjes@google.com" <rientjes@google.com>,
	"jiaqiyan@google.com" <jiaqiyan@google.com>,
	"tony.luck@intel.com" <tony.luck@intel.com>,
	"Jon.Grimm@amd.com" <Jon.Grimm@amd.com>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"rafael@kernel.org" <rafael@kernel.org>,
	"lenb@kernel.org" <lenb@kernel.org>,
	"naoya.horiguchi@nec.com" <naoya.horiguchi@nec.com>,
	"james.morse@arm.com" <james.morse@arm.com>,
	"jthoughton@google.com" <jthoughton@google.com>,
	"somasundaram.a@hpe.com" <somasundaram.a@hpe.com>,
	"erdemaktas@google.com" <erdemaktas@google.com>,
	"pgonda@google.com" <pgonda@google.com>,
	"duenwen@google.com" <duenwen@google.com>,
	"mike.malvestuto@intel.com" <mike.malvestuto@intel.com>,
	"gthelen@google.com" <gthelen@google.com>,
	"wschwartz@amperecomputing.com" <wschwartz@amperecomputing.com>,
	"dferguson@amperecomputing.com" <dferguson@amperecomputing.com>,
	"wbs@os.amperecomputing.com" <wbs@os.amperecomputing.com>,
	"nifan.cxl@gmail.com" <nifan.cxl@gmail.com>,
	tanxiaofei <tanxiaofei@huawei.com>,
	"Zengtao (B)" <prime.zeng@hisilicon.com>,
	"kangkang.shen@futurewei.com" <kangkang.shen@futurewei.com>,
	wanghuiqiang <wanghuiqiang@huawei.com>,
	Linuxarm <linuxarm@huawei.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jean Delvare <jdelvare@suse.com>,
	Guenter Roeck <linux@roeck-us.net>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>
Subject: Re: [RFC PATCH v8 01/10] ras: scrub: Add scrub subsystem
Message-ID: <20240527092131.GBZlRQmxwFTxxyR20q@fat_crate.local>
References: <D9511DC1-1566-473A-A426-111BB1F7F9F0@alien8.de>
 <20240509200306.GAZj0r-h5Tnc0ecIOz@fat_crate.local>
 <663d3e58a0f73_1c0a1929487@dwillia2-xfh.jf.intel.com.notmuch>
 <20240509215147.GBZj1Fc06Ieg8EQfnR@fat_crate.local>
 <663d55515a2d9_db82d2941e@dwillia2-xfh.jf.intel.com.notmuch>
 <20240510092511.GBZj3n9ye_BCSepFZy@fat_crate.local>
 <663e55c59d9d_3d7b429475@dwillia2-mobl3.amr.corp.intel.com.notmuch>
 <20240511101705.GAZj9FoVbThp7JUK16@fat_crate.local>
 <6645f0738ead48a79f1baf753fc709c6@huawei.com>
 <20240520125857.00007641@Huawei.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240520125857.00007641@Huawei.com>

On Mon, May 20, 2024 at 12:58:57PM +0100, Jonathan Cameron wrote:
> > 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.

This is all talking about what hw functionality there is. I'm more
interested in the "there is a need" thing. What need? How?

In order to support something like this upstream, I'd like to know how
it is going to be used and whether the major use cases are covered. So
that everyone can benefit from it - not only your employer.

> > 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.

Who's going to use those scrub controls? Tools? Admins? Scripts?

> > 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.

Yah, that's not my question: my question is, how is this new thing,
which is exposed to userspace and which then means, this will be
supported forever, how is this thing going to be used?

And the next question is: is that interface sufficient for those use
cases?

Are we covering the majority of the usage scenarios?

> 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.

Yes, I get that: question is, let's say you have that interface. Now
what do you do?

Do you go and start a scrub cycle by hand?

Do you have a script which does that based on some system reports?

Do you automate it? I wanna say yes because that's miles better than
having to explain yet another set of knobs to users.

And so on and so on...

I'm trying to get you to imagine the *full* solution and then ask
yourselves whether that new interface is adequate.

Makes more sense?

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette