Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu 2018-01-11 16:36:18, Sergey Senozhatsky wrote:
> Hi Mathieu,
> 
> On (01/10/18 18:40), Mathieu Desnoyers wrote:
> [..]
> > 
> > There appears to be two problems at hand. One is making sure a console
> > buffer owner only flushes a bounded amount of data.
> 
> which, realistically, has quite little to do with the "and thus it
> fixes the lockups". logbuf size is mutable, the number of consoles we
> need to sequentially push the data to is mutable, the watchdog threshold
> is mutable... if combination of first two mutable things produces the
> result which makes the check based on the third mutable thing happy,
> then it's just an accident. my 5 cents.

Yes, there might be situations when Steven's patch is not able to
prevent the softlockup. But there is clear evidence that it will
help in many other situations.

The offload-based solution prevents the softlockup completely.
But there might be situations where the offload does not happen
and people might miss important messages.

And this is my point. Steven's patch is not perfect. But it helps
and it seems that it does not cause regressions. The offload based
solution solves one problem a better way but it might cause
regressions that are being discussed for years.


IMHO, nobody know how much Steven's solution is effective until we
push it into the wild. IMHO, it is safe to be pushed.

You might argue that we already know that Steven's solution will
not be enough. IMHO, the problem here is the term "real life example".

My understanding is that real-life example is a softlockup report
from a system running in production or used for debugging any bug.
So far, Steven's opponents provided only hand made code or
scenarios. The provided code usually produced printk() messages
in a tight loop. In each case, there is not a consensus that they
simulated a real life problem good enough. We might continue
discussing it but basically any discussion is theoretical unless
there are hard data behind it.

I vote to push Steven's patch into the wild and see. I really would
like to give it a chance.

Best Regards,
Petr

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]
  Powered by Linux