lkml.org 
[lkml]   [2022]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH printk v1 11/13] printk: reimplement console_lock for proper kthread support
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

\
 
 \ /
  Last update: 2022-02-24 09:27    [W:0.454 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site