Messages in this thread |  | | Date | Sat, 13 Jan 2018 16:31:00 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup |
| |
On (01/12/18 13:55), Petr Mladek wrote: [..] > > I'm not fixing console_unlock(), I'm fixing printk(). BTW, all my > > kernels are CONFIG_PREEMPT (I'm a RT guy), my mind thinks more about > > PREEMPT kernels than !PREEMPT ones. > > I would say that the patch improves also console_unlock() but only in > non-preemttive context. > > By other words, it makes console_unlock() finite in preemptible context > (limited by buffer size). It might still be unlimited in > non-preemtible context.
could you elaborate a bit?
[..] > > > reverting 6b97a20d3a7909daa06625d4440c2c52d7bf08d7 may be the right > > > thing after all. > > > > I would analyze that more before doing so. Because with my patch, I > > think we make those that can do long prints (without triggering a > > watchdog), the ones most likely doing the long prints. > > IMHO, it might make sense because it would help to see the messages > faster. But I would prefer to handle this separately because it > might also increase the risk of softlockups. Therefore it might > cause regressions. > > We should also take into account the commit 8d91f8b15361dfb438ab6 > ("printk: do cond_resched() between lines while outputting to > consoles"). It has the same effect for console_lock() callers.
I replied in another email.
-ss
|  |