2012/10/30 Steven Rostedt :
> Probably need to at least disable preemption. I don't see any
> requirement that wake_up_klogd() needs to be called with preemption
> disabled.
>
> The this_cpu_or() doesn't care which CPU it triggers, but the enabling
> of nohz does.
This patch is deemed to be
On Mon, 2012-10-29 at 16:27 -0400, Steven Rostedt wrote:
> plain text document attachment
> (0010-nohz-cpuset-Restart-the-tick-if-printk-needs-it.patch)
> From: Frederic Weisbecker
>
> If we are in nohz adaptive mode and printk is called, the tick is
> missing to wake up the logger. We need to
On Mon, 2012-10-29 at 16:27 -0400, Steven Rostedt wrote:
plain text document attachment
(0010-nohz-cpuset-Restart-the-tick-if-printk-needs-it.patch)
From: Frederic Weisbecker fweis...@gmail.com
If we are in nohz adaptive mode and printk is called, the tick is
missing to wake up the logger.
2012/10/30 Steven Rostedt rost...@goodmis.org:
Probably need to at least disable preemption. I don't see any
requirement that wake_up_klogd() needs to be called with preemption
disabled.
The this_cpu_or() doesn't care which CPU it triggers, but the enabling
of nohz does.
This patch is
From: Frederic Weisbecker
If we are in nohz adaptive mode and printk is called, the tick is
missing to wake up the logger. We need to restart the tick when that
happens. Do this asynchronously by issuing a tick restart self IPI
to avoid deadlocking with the current random locking chain.
From: Frederic Weisbecker fweis...@gmail.com
If we are in nohz adaptive mode and printk is called, the tick is
missing to wake up the logger. We need to restart the tick when that
happens. Do this asynchronously by issuing a tick restart self IPI
to avoid deadlocking with the current random
6 matches
Mail list logo
