Messages in this thread |  | | Date | Tue, 16 Jan 2018 15:10:13 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup |
| |
Hi,
On (01/15/18 12:50), Petr Mladek wrote: > On Mon 2018-01-15 11:17:43, Petr Mladek wrote: > > PS: Sergey, you have many good points. The printk-stuff is very > > complex and we could spend years discussing the perfect solution. > > BTW: One solution that comes to my mind is based on ideas > already mentioned in this thread: > > void console_unlock(void) > { > disable_preemtion(); > > while(pending_message) { > > call_console_drivers(); > > if (too_long_here() && current != printk_kthread) { > wake_up_process(printk_kthread()) > > } > > enable_preemtion(); > }
unfortunately disabling preemtion in console_unlock() is a bit dangerous :( we have paths that call console_unlock() exactly to flush everything (not only new pending messages, but everything) that is in logbuf and we cannot return from console_unlock() preliminary in that case.
> bool too_long_here(void) > { > return should_resched(); > or > return spent_here() > 1 / HZ / 2; > or > what ever we agree on > } > > > int printk_kthread_func(void *data) > { > while(1) { > if (!pending_messaged) > schedule(); > > if (console_trylock_spinning()) > console_unlock(); > > cond_resched(); > } > }
overall that's very close to what I have in one of my private branches. console_trylock_spinning() for some reason does not perform really well on my made-up internal printk torture tests. it seems that I have a much better stability (no lockups and so on) when I also let printk_kthread to sleep on console_sem(). but I will look further.
-ss
|  |