Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

[Petr Mladek]

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();
}

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();
	}
}

It means that console_unlock() will aggressively push messages
with disabled preemption. It will wake up printk_kthread when
it is pushing too long. The printk_kthread would try
to steal the lock and take over the job.

If the system is in reasonable state, printk_kthread should
succeed and avoid softlockup. The offload should be more safe
than a pure wake_up_process().

If printk_kthread is not able to take over the job, it
might suggest that the offload is not safe and the softlockup
is inevitable.

One question is how to avoid softlockup when console_unlock()
is called from printk_kthread. I think that printk_kthread
should release console_lock and call cond_resched from
time to time. It means that the printing will be less
aggressive but anyone could continue flushing the console.
If there are no new messages, it is probably acceptable
to be less aggressive with flushing the messages.


Anyway, this should be more safe than a direct offload
if we agree that getting the messages out is more
important than a possible softlockup.

If this is not enough, I would start thinking about
throttling writers.

Finally, this is all a future work that can be done
and discussed later.

Best Regards,
Petr