On Tue 2020-10-13 19:46:32, Tetsuo Handa wrote: > On 2020/10/13 18:02, Petr Mladek wrote: > > On Tue 2020-10-13 09:40:27, Tetsuo Handa wrote: > >> Proper ratelimiting for OOM messages had better not to count on asynchronous printk(). > > > > I am a bit confused. AFAIK, you wanted to print OOM messages > > asynchronous ways in the past. The lockless printk ringbuffer is on > > its way into 5.10. Handling consoles in kthreads will be the next > > step of the printk rework. > > What I'm proposing is synchronously printing OOM messages from a different > thread, for one dump_tasks() call can generate thousands of lines which may > significantly delay arrival of non OOM related messages to consoles (or even > drop due to logbuf being full). I don't want to enqueue too many OOM related > messages to logbuf, even after printk() became completely asynchronous. This looks like a lot of complexity. I am not convinced that it is worth it. I could understand that people heavily testing OOM behavior meet this problem. But I wonder how many people really meet this problem in the real life. > > Could you please provide some examples how you would tune ratelimit > > when printing all messages to the console takes X ms and OOM > > happens every Y ms? > > My proposal is to decide whether to print the new report based on > whether all OOM candidates for that OOM domain have been flushed to > consoles. There is no X and Y. >From the printk() point of view, we need an API that would provide information whether a given message reached the consoles or not. Then it would be up to the MM-code to use it. One catch might be when console_seq is synchronized by console_lock. Because the caller of this API would become responsible for flushing all existing messages. But it should be usable. It is currently synchronized also by logbuf_lock. Best Regards, Petr
