Re: [PATCH v13 6/9] cxl/memdev: Add trigger_poison_list sysfs attribute

[Alison Schofield <alison.schofield@intel.com>]

On Thu, Apr 27, 2023 at 09:35:02AM -0700, Dan Williams wrote:
> Davidlohr Bueso wrote:
> > On Wed, 26 Apr 2023, Alison Schofield wrote:
> > 
> > >At the moment, I have 'trigger_scan_media' that results in a spew of
> > >scan media results to a trace file. I guess we'll chat more about
> > >presenting a _nocache, when I post for review.
> > 
> > I'm not crazy about calling the interface scan media straight how just
> > because it's very unintuitive - albeit users that care will probably
> > don't care.
> > 
> > >
> > >I'm concerned that a  _nocache_ will lead user to believe they are
> > >getting 'fresher' results, and to over-use it with that mindset.
> > 
> > Agreed.
> > 
> > >Get Poison List gives accurate results and Scan Media is only necessary
> > >when the poison list has overflowed. OK...here I go opening the can of
> > >worms myself ;)
> > 
> > trigger_poison_list_overflow?
> > 
> > If triggered and the list hasn't overflowed yet, just be a nop?
> 
> What about a "poison_overflow" policy? Defaults to "report", but you can
> write "scan" to have trigger_poison_list invocations fallback to
> scan_media on overflow.

With a policy like that, the driver may automatically do scan media
in response to overflow reports.

For users that want to schedule those scans (policy set to 'report'),
they can do so my doing trigger_scan_media at their leisure.

Would you expect the driver to retain overflow state, and warn those
users that they are issuing scan_media without prior overflow events?