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). > > > thanks, > -- > John Hubbard > NVIDIA >
