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
--
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>
