Re: [PATCH] x86/fault: speed up uffd-unit-test by 10x: rate-limit "MCE: Killing" logs

[John Hubbard]

On 5/7/24 11:15 AM, Axel Rasmussen wrote:
> On Tue, May 7, 2024 at 11:11 AM John Hubbard <jhubbard@xxxxxxxxxx> wrote:
> > On 5/7/24 11:08 AM, Axel Rasmussen wrote:
> > > On Tue, May 7, 2024 at 9:43 AM David Hildenbrand <david@xxxxxxxxxx> wrote:
> > ...
> > > > > That thread seems to have stalled.
> > > >
> > > > Yes, there was no follow-up.
> > >
> > > Apologies, I had completely forgotten about this. I blame the weekend. :)
> > >
> > > No objections from me to the simple rate limiting proposed here, if
> > > useful you can take:
> > >
> > > Acked-by: Axel Rasmussen <axelrasmussen@xxxxxxxxxx>
> > >
> > > But, it seems to me the earlier proposal may still be useful.
> > > Specifically, don't print at all for "synthetic" poisons from
> > > UFFDIO_POISON or similar mechanisms. This way, "real" errors aren't
> > > gobbled up by the ratelimit due to spam from "synthetic" errors. If
> > > folks agree, I can *actually* send a patch this time. :)
> >
> > That sounds good to me. (Should it also rate limit, though? I'm leaning
> > toward yes.)
>
> I believe the proposal so far was, simulated poisons aren't really
> "global" events, and are only relevant to the process itself. So don't
> send them to the global kernel log at all, and instead let the process
> do whatever it wants with them (e.g. it could print something when it
> receives a signal, perhaps with rate limiting).
 
OK. And seeing as how I'm not (at all) in alignment with Borislav on
where to apply rate limiting, we'd better go with your approach.


thanks,
--
John Hubbard
NVIDIA