Messages in this thread | | | Date | Thu, 24 Feb 2022 09:27:04 +0100 | From | Petr Mladek <> | Subject | Re: [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
| |