RE: [PATCH v12 1/2] ACPI:RAS2: Add ACPI RAS2 driver

[Shiju Jose <shiju.jose@huawei.com>]

>-----Original Message-----
>From: Borislav Petkov <bp@alien8.de>
>Sent: 19 September 2025 11:40
>To: Jonathan Cameron <jonathan.cameron@huawei.com>
>Cc: Shiju Jose <shiju.jose@huawei.com>; rafael@kernel.org; akpm@linux-
>foundation.org; rppt@kernel.org; dferguson@amperecomputing.com; linux-
>edac@vger.kernel.org; linux-acpi@vger.kernel.org; linux-mm@kvack.org; linux-
>doc@vger.kernel.org; tony.luck@intel.com; lenb@kernel.org;
>Yazen.Ghannam@amd.com; mchehab@kernel.org; Linuxarm
><linuxarm@huawei.com>; rientjes@google.com; jiaqiyan@google.com;
>Jon.Grimm@amd.com; dave.hansen@linux.intel.com;
>naoya.horiguchi@nec.com; james.morse@arm.com; jthoughton@google.com;
>somasundaram.a@hpe.com; erdemaktas@google.com; pgonda@google.com;
>duenwen@google.com; gthelen@google.com;
>wschwartz@amperecomputing.com; wbs@os.amperecomputing.com;
>nifan.cxl@gmail.com; tanxiaofei <tanxiaofei@huawei.com>; Zengtao (B)
><prime.zeng@hisilicon.com>; Roberto Sassu <roberto.sassu@huawei.com>;
>kangkang.shen@futurewei.com; wanghuiqiang <wanghuiqiang@huawei.com>
>Subject: Re: [PATCH v12 1/2] ACPI:RAS2: Add ACPI RAS2 driver
>
>On Wed, Sep 17, 2025 at 06:36:08PM +0100, Jonathan Cameron wrote:
>> This 'first contiguous range' is an attempt to DTRT in a corner case
>> that is real but where there is not an obvious right thing due to spec
>limitations.
>
>Thanks for taking the time to expand. The gist of this needs to be in a commit
>message for future reference.
>
>HOWEVER, I'm still not clear *why* we're jumping through hoops which we
>probably set up ourselves without even knowing why... at least it looks like this
>from where I'm standing.
>
>So why not start a scrub on the whole system? Why do we care?
>
>Scrub is "cheap" in the sense that it runs in the background and is the lowest
>priority and everything else overrides it.
>
>So why design an interface only when there's a need to design one and do the
>simplest thing now, for starters? Gather some experience and then imrpove it by
>actually designing an interface...

Hi Boris,

Sorry for the delay in replaying.

We have a prototype looking to simplify things as follows (leaving per node and
range control for future work), but before I post it (waiting for rc1) I'd like to discuss
the approach and a few open questions"

1.Scrub rate
1.1. Scrub rate is common across the NUMA node domains.
1.2. Common min scrub rate is max of min scrub rates across nodes.
1.3. Common max scrub rate is min of max scrub rates across nodes.
1.4. Scrub rate allowed to change only if NO demand and patrol
   scrubbing is in progress and should be within min and max
   range of scrub rates.

2. Demand scrubbing and Background (patrol) scrubbing
2.1. Background scrubbing request enables BG scrubbing
     on all NUMA nodes.

2.2. For, demand scrubbing request 2 options are identified,
     with (b) tried. Please suggest the right approach?
a) Enable demand scrubbing on all NUMA nodes, hope for
     the 'Requested Address Range(INPUT)' field, can use
     address set to scrub and PAGE_SIZE(or similar) for all the
     nodes. For RAS2, only 'addr' sysfs attribute is added now
     and 'size' sysfs attribute is removed.
b) Enable demand scrubbing on a NUMA node for which
     the requested address to scrub is within the PA range of
     that node.

2.3. Demand scrubbing is not allowed when background scrubbing
     is in progress.

2.4. If 2.2. (b) is chosen, should kernel allow BG
      scrubbing on rest of the nodes, when demand scrubbing on
      some node/s is in progress?

2.5 The status of the BG scrubbing exposed to the user space
    in 'enable_background' sysfs attribute.

2.6 The status of the demand scrubbing exposed to the
       user space in 'addr' sysfs attribute. However when the
       demand scrubbing is on multiple/all nodes are in progress,
       which demand scrubbing status and address in 'addr' sysfs attribute
       as status should be exposed to the user space?
a) May be the status of the first detected node with demand scrubbing
     is in progress?
b) Does not show the status at all, just fail the request if the
    demand scrubbing is already in progress on a node/all nodes?
c)  Any other suggestion?

Thanks,
Shiju

>
>Thx.
>
>--
>Regards/Gruss,
>    Boris.
>
>https://people.kernel.org/tglx/notes-about-netiquette