Re: [Ksummit-discuss] [TECH TOPIC] printk redesign

[Petr Mladek <pmladek@suse.com>]

On Tue 2017-06-20 20:45:27, Daniel Vetter wrote:
> My own pet peeve with printk from the drm side:
> 
> Untangling printk form the console_lock horror show, if at all
> possible. One problem is that heavy printk usage makes the
> console_lock massively contended (we delay restoring the the kernel
> console on resume in kms drivers to a worker because of that).

We really need an offload mechanism. The patches are circulating
for years. The last version uses a kthread. It allows to release
console_lock even when some messages are pending. It should be
perfectly fine when the system works normally and the kthread
will get scheduled eventually.

There is a problem to detect situations where the system is
in a bad state, the offload might not work and we should switch
to the sync mode. But we make some progress on this as well.

IMHO, the best solution would be to avoid sleeping with
console_lock. Then it will be guaranteed that either someone
is actively flushing the messages or that anyone else is
free to do so.

But this would require to untangle all the other uses of
console_lock where the sleeping is necessary these days.

Also others might think different.

Anyway, the discussion about the current patchset is at
https://lkml.kernel.org/r/20170509082859.854-3-sergey.senozhatsky@gmail.com

Sergey already have another RFC using another idea but I did
not have to review this yet. See
https://lkml.kernel.org/r/20170602090345.624-1-sergey.senozhatsky@gmail.com



> The worse problem is that console_lock locking is horribly monolithic and
> defacto requires that large chunks of your gfx driver init code needs
> to run while holding it. Which means no printk output, neither for
> your gfx driver nor anything else while your cpu goes through
> something like a few 100k lines of code (for big drivers).

To be honest, I still do not know all the dark sides of the console
handling and this seems to be one of them. I wonder why
the console_lock is needed in this code. It does not make
much sense to me. It must be a synchronization task of
console_lock that I not aware of.


> We have a few pages of kerneldoc explaining how to debug this and what
> happens, and gross debug hacks to just not take console_lock on driver
> (and pray it won't race), but it's a constant trap for new gfx
> hackers.

Good to know.

> Fixing console_lock is much less likely to happen, I (and better
> hackers like Alan Cox) tried, and ran away in tears.

This looks like a real challenge. I feel less shame that it take
us too long.

Best Regards,
Petr