On Tue, May 28, 2024 at 10:06:45AM +0100, Jonathan Cameron wrote:
> If dealing with disabling, I'd be surprised if it was a normal policy but
> if it were udev script or boot script. If unusual event (i.e. someone is
Yeah, I wouldn't disable it during boot but around my workload only. You
want for automatic scrubs to still happen on the system.
> trying to reduce jitter in a benchmark targetting something else) then
> interface is simple enough that an admin can poke it directly.
Right, for benchmarks direct poking is fine.
When it is supposed to be something more involved like, dunno, HPC doing
a heavy workload and it wants to squeeze all performance so I guess
turning off the scrubbers would be part of the setup script. So yeah, if
this is properly documented, scripting around it is easy.
> To a certain extent this is bounded by what the hardware lets us
> do but agreed we should make sure it 'works' for the usecases we know
> about. Starting point is some more documentation in the patch set
> giving common flows (and maybe some example scripts).
Yap, sounds good. As in: "These are the envisioned usages at the time of
writing... " or so.
> > Do you go and start a scrub cycle by hand?
>
> Typically no, but the option would be there to support an admin who is
> suspicious or who is trying to gather statistics or similar.
Ok.
> That definitely makes sense for NVDIMM scrub as the model there is
> to only ever do it on a demand as a single scrub pass.
> For a cyclic scrub we can spin a policy in rasdaemon or similar to
> possibly crank up the frequency if we are getting lots of 'non scrub'
> faults (i.e. correct error reported on demand accesses).
I was going to suggest that: automating stuff with rasdaemon. It would
definitely simplify talking to that API.
> Shiju is our expert on this sort of userspace stats monitoring and
> handling so I'll leave him to come back with a proposal / PoC for doing that.
>
> I can see two motivations though:
> a) Gather better stats on suspect device by ensuring more correctable
> error detections.
> b) Increase scrubbing on a device which is on it's way out but not replacable
> yet for some reason.
>
> I would suggest this will be PoC level only for now as it will need
> a lot of testing on large fleets to do anything sophisticated.
Yeah, sounds like a good start.
> > Do you automate it? I wanna say yes because that's miles better than
> > having to explain yet another set of knobs to users.
>
> First instance, I'd expect an UDEV policy so when a new CXL memory
> turns up we set a default value. A cautious admin would have tweaked
> that script to set the default to scrub more often, an admin who
> knows they don't care might turn it off. We can include an example of that
> in next version I think.
Yes, and then hook into rasdaemon the moment it logs an error in some
component to go and increase scrubbing of that component. But yeah, you
said that above already.
> Absolutely. One area that needs to improve (Dan raised it) is
> association with HPA ranges so we at can correlate easily error reports
> with which scrub engine. That can be done with existing version but
> it's fiddlier than it needs to be. This 'might' be a userspace script
> example, or maybe making associations tighter in kernel.
Right.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
