Re: [PATCH printk v1 11/13] printk: reimplement console_lock for proper kthread support

[Petr Mladek <pmladek@suse.com>]

On Wed 2022-02-23 18:26:54, John Ogness wrote:
> On 2022-02-22, Petr Mladek <pmladek@suse.com> wrote:
> >> With a mutex there is an owner. When another task tries to lock a
> >> mutex, the scheduler knows which task must be scheduled to resolve
> >> this true lock contention. (There are also other benefits relating to
> >> priority inheritance, but I chose not to mention this.)
> >
> > This sounds interesting. Does scheduler wake up or prioritize
> > mutex owners?
> 
> Sorry, the only example of this is priority inheritance. But for
> non-PREEMPT_RT there is no priority inheritance. The lock would need to
> be an rtmutex for this ability, which probably doesn't make sense for
> printk.

Good to know.

> The v2 commit message will focus on:
> 
> - the motivation for per-console locks is parallel printing
> 
> - explain about how disabling preemption is only necessary for direct
>   printing via printk() because the caller may be holding
>   system-critical and/or timing-sensitive locks (and also to allow the
>   console owner/waiter logic to work correctly)
> 
> - correctly clarifying why the various types
>   (semaphore/mutex/flag/atomic) were chosen to implement the printing
>   sychronization between atomic-direct, non-atomic-direct, and kthreads
>   (and I will explicitly remind the audience that mutex_trylock() cannot
>   be used in atomic context)

Sounds great.

Thanks a lot for the hard work. It is very appreciated.

Best Regards,
Petr