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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>