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>
