On Thu, 9 Nov 2017 09:56:35 +0900 Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx> wrote: > Hello Steven, > > On (11/08/17 09:29), Steven Rostedt wrote: > > On Wed, 8 Nov 2017 14:19:55 +0900 > > Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx> wrote: > > > > > the change goes further. I did express some of my concerns during the KS, > > > I'll just bring them to the list. > > > > > > > > > we now always shift printing from a save - scheduleable - context to > > > a potentially unsafe one - atomic. by example: > > > > And vice versa. We are now likely to go from a unscheduleable context > > to a schedule one, where before, that didn't exist. > > the existence of "and vice versa" is kinda alarming, isn't it? it's sort > of "yes, we can break some things, but we also can improve some things." Not really. Because the heuristic is that what calls printk will do the printk. > > > And my approach, makes it more likely that the task doing the printk > > prints its own message, and less likely to print someone else's. > > > > > > > > CPU0 CPU1~CPU10 CPU11 > > > > > > console_lock() > > > > > > printk(); > > > > > > console_unlock() IRQ > > > set console_owner printk() > > > sees console_owner > > > set console_waiter > > > sees console_waiter > > > break > > > console_unlock() > > > ^^^^ lockup [?] > > > > How? > > oh, yes, the missing part - assume CPU1~CPU10 did 5000 printk() calls, > while console_sem was locked on CPU0. then we console_unlock() from CPU0 > and shortly after IRQ->printk() from CPU11 forcibly takes over, so now > we are in console_unlock() from atomic, printing some 5000 messages. I'd say remove those 5000 printks ;-) -- Steve -- 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>