From: Arjan van de Ven <arjan@linux.intel.com>
To: richard -rw- weinberger <richard.weinberger@gmail.com>
Cc: penberg@cs.helsinki.fi, LKML <linux-kernel@vger.kernel.org>,
user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [REGRESSION] um: rcu_sched_state detected stall on CPU 0
Date: Thu, 14 Oct 2010 12:50:29 -0700 [thread overview]
Message-ID: <4CB75F05.9070505@linux.intel.com> (raw)
In-Reply-To: <AANLkTinNxzktyttzEjWSUPBiOUwh+4DUL0tmP7p1UiT5@mail.gmail.com>
On 10/14/2010 11:27 AM, richard -rw- weinberger wrote:
> Hi Arjan!
>
> This commit causes some problems on UML.
>
that is extremely weird.
> The kernel freezes after a few seconds until it gets some input.
> e.g: When I run top it stops refreshing the process list until i press a button.
a slab timer change (to not be as critical) causing global timer
issues.... that's very obviously not a problem with this patch.
has this been seem anywhere except UML ?
> Messages like this appear:
> INFO: rcu_sched_state detected stall on CPU 0 (t=7348 jiffies)
>
> After reverting UML works fine again.
>
> commit 78b435368fcd615e695a06012cd963a556284e00
> Author: Arjan van de Ven<arjan@linux.intel.com>
> Date: Mon Jul 19 10:59:42 2010 -0700
>
> slab: use deferable timers for its periodic housekeeping
>
> slab has a "once every 2 second" timer for its housekeeping.
> As the number of logical processors is growing, its more and more
> common that this 2 second timer becomes the primary wakeup source.
>
> This patch turns this housekeeping timer into a deferable timer,
> which means that the timer does not interrupt idle, but just runs
> at the next event that wakes the cpu up.
>
> The impact is that the timer likely runs a bit later, but during the
> delay no code is running so there's not all that much reason for
> a difference in housekeeping to occur because of this delay.
>
> Signed-off-by: Arjan van de Ven<arjan@linux.intel.com>
> Signed-off-by: Pekka Enberg<penberg@cs.helsinki.fi>
>
> diff --git a/mm/slab.c b/mm/slab.c
> index e49f8f4..29aad44 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -861,7 +861,7 @@ static void __cpuinit start_cpu_timer(int cpu)
> */
> if (keventd_up()&& reap_work->work.func == NULL) {
> init_reap_node(cpu);
> - INIT_DELAYED_WORK(reap_work, cache_reap);
> + INIT_DELAYED_WORK_DEFERRABLE(reap_work, cache_reap);
> schedule_delayed_work_on(cpu, reap_work,
> __round_jiffies_relative(HZ, cpu));
> }
>
>
next prev parent reply other threads:[~2010-10-14 19:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-14 18:27 [REGRESSION] um: rcu_sched_state detected stall on CPU 0 richard -rw- weinberger
2010-10-14 19:50 ` Arjan van de Ven [this message]
2010-10-14 20:06 ` richard -rw- weinberger
2010-10-14 23:44 ` richard -rw- weinberger
2010-10-15 7:02 ` Pekka Enberg
2010-10-15 7:48 ` Peter Zijlstra
2010-10-15 9:24 ` richard -rw- weinberger
2010-10-16 15:27 ` richard -rw- weinberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CB75F05.9070505@linux.intel.com \
--to=arjan@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@cs.helsinki.fi \
--cc=richard.weinberger@gmail.com \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox