From: Srivatsa Vaddagiri <vatsa@in.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Amit K. Arora" <aarora@linux.vnet.ibm.com>,
tj@kernel.org, Ingo Molnar <mingo@elte.hu>,
Gautham R Shenoy <ego@in.ibm.com>,
Darren Hart <dvhltc@us.ibm.com>,
Brian King <brking@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Make sure timers have migrated before killing migration_thread
Date: Mon, 24 May 2010 20:46:55 +0530 [thread overview]
Message-ID: <20100524151655.GF13808@linux.vnet.ibm.com> (raw)
In-Reply-To: <1274707726.5605.31932.camel@twins>
On Mon, May 24, 2010 at 03:28:45PM +0200, Peter Zijlstra wrote:
> On Mon, 2010-05-24 at 15:29 +0530, Amit K. Arora wrote:
> > since _cpu_up() and _cpu_down() can never run in
> > parallel, because of cpu_add_remove_lock.
>
> Ah indeed. I guess your initial patch works then.
One thing I found surprising was that a cpu's rt-bandwidth renewal could be
dependant on another cpu's (rt-bandwidth) timer firing ontime. In this case, we
had migration/23 pulled over to CPU0 and we hung later waiting for migration/23
to exit. migration/23 was not exiting because it could not run on CPU0 (as
CPU0's rt-bandwidth had expired). This situation remained forever. I would have
expected CPU0's bandwidth to have been renewed independent of some timer on
CPU23 to fire - maybe I am missing something not obvious in the code?
- vatsa
next prev parent reply other threads:[~2010-05-24 15:17 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-19 9:05 [PATCH] Make sure timers have migrated before killing migration_thread Amit K. Arora
2010-05-19 9:31 ` Peter Zijlstra
2010-05-19 12:13 ` [PATCH v2] " Amit K. Arora
2010-05-20 7:28 ` Peter Zijlstra
2010-05-23 9:07 ` Mike Galbraith
2010-05-23 9:13 ` Peter Zijlstra
2010-05-24 6:43 ` Amit K. Arora
2010-05-25 20:19 ` Thomas Gleixner
2010-05-26 6:43 ` Peter Zijlstra
2010-05-24 9:59 ` [PATCH] " Amit K. Arora
2010-05-24 13:28 ` Peter Zijlstra
2010-05-24 15:16 ` Srivatsa Vaddagiri [this message]
2010-05-24 15:55 ` Peter Zijlstra
2010-05-25 11:31 ` Peter Zijlstra
2010-05-25 12:10 ` Amit K. Arora
2010-05-25 13:23 ` [PATCH v3] " Amit K. Arora
2010-05-25 14:22 ` Peter Zijlstra
2010-05-25 16:27 ` Tejun Heo
2010-05-31 7:18 ` [tip:sched/urgent] sched: Make sure timers have migrated before killing the migration_thread tip-bot for Amit K. Arora
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=20100524151655.GF13808@linux.vnet.ibm.com \
--to=vatsa@in.ibm.com \
--cc=aarora@linux.vnet.ibm.com \
--cc=brking@linux.vnet.ibm.com \
--cc=dvhltc@us.ibm.com \
--cc=ego@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=tj@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.