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
