Re: [PATCH] mm: don't warn about allocations which stall for too long

[Vlastimil Babka]

On 10/31/2017 08:32 PM, Steven Rostedt wrote:
> 
> Thank you for the perfect timing. You posted this the day after I
> proposed a new solution at Kernel Summit in Prague for the printk lock
> loop that you experienced here.
> 
> I attached the pdf that I used for that discussion (ignore the last
> slide, it was left over and I never went there).
> 
> My proposal is to do something like this with printk:
> 
> Three types of printk usages:
> 
> 1) Active printer (actively writing to the console).
> 2) Waiter (active printer, first user)
> 3) Sees active printer and a waiter, and just adds to the log buffer
>    and leaves.
> 
> (new globals)
> static DEFINE_SPIN_LOCK(console_owner_lock);
> static struct task_struct console_owner;
> static bool waiter;
> 
> console_unlock() {
> 
> [ Assumes this part can not preempt ]
> 
> 	spin_lock(console_owner_lock);
> 	console_owner = current;
> 	spin_unlock(console_owner_lock);
> 
> 	for each message
> 		write message out to console
> 
> 		if (READ_ONCE(waiter))
> 			break;

Ah, these two lines clarified for me what I didn't get from your talk,
so I got the wrong impression that the new scheme is just postponing the
problem.

But still, it seems to me that the scheme only works as long as there
are printk()'s coming with some reasonable frequency. There's still a
corner case when a storm of printk()'s can come that will fill the ring
buffers, and while during the storm the printing will be distributed
between CPUs nicely, the last unfortunate CPU after the storm subsides
will be left with a large accumulated buffer to print, and there will be
no waiters to take over if there are no more printk()'s coming. What
then, should it detect such situation and defer the flushing?