Re: How to avoid printk() delay caused by cond_resched() ?

[Petr Mladek <pmladek@suse.com>]

On Wed 2016-03-02 23:34:15, Sergey Senozhatsky wrote:
> On (03/02/16 14:38), Petr Mladek wrote:
> [..]
> > > 
> > > CONFIG_PREEMPT_NONE=y
> > > # CONFIG_PREEMPT_VOLUNTARY is not set
> > > # CONFIG_PREEMPT is not set
> > > CONFIG_PREEMPT_COUNT=y
> > 
> > preempt_disable() / preempt_enable() would do the job.
> > The question is where to put it. If you are concerned about
> > the delay, you might want to disable preemption around
> > the whole locked area, so that it works reasonable also
> > in the preemptive kernel.
> 
> another question is why cond_resched() is suddenly so expensive?

My guess is that nobody called cond_resched() in this OOM path on
non-preemptible kernel before.

> my guess is because of OOM, so we switch to tasks that potentially
> do direct reclaims, etc. if so, then even offloaded printk will take
> a significant amount of time to print the logs to the consoles; just
> because it does cond_resched() after every call_console_drivers().

IMHO, calling cond_resched() is just an offer that the process
is ready to get rescheduled at this point. It will reschedule only
if the process is over its dedicated time slot or if a higher
priority task appeared in the run queue. IMHO, it is perfectly fine
to call is often.

Best Regards,
Petr

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>