From: jszhang@marvell.com (Jisheng Zhang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/2] irqchip: dw-apb-ictl: add irq_set_affinity support
Date: Sat, 4 Jul 2015 17:43:42 +0800 [thread overview]
Message-ID: <20150704174342.3fc8bd67@xhacker> (raw)
In-Reply-To: <20150704173533.39919c40@xhacker>
Dear Russell,
On Sat, 4 Jul 2015 17:35:33 +0800
Jisheng Zhang <jszhang@marvell.com> wrote:
> Dear Russell,
>
> On Sat, 4 Jul 2015 10:25:46 +0100
> Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>
> > On Sat, Jul 04, 2015 at 04:50:07PM +0800, Jisheng Zhang wrote:
> > > Dear Russell,
> > >
> > > On Sat, 4 Jul 2015 09:26:23 +0100
> > > Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > >
> > > > On Sat, Jul 04, 2015 at 01:19:30PM +0800, Jisheng Zhang wrote:
> > > > > On Marvell Berlin SoCs, the cpu's local timer is shutdown when the cpu
> > > > > goes to a deep idle state, then the timer framework will be notified to
> > > > > use a broadcast timer instead. The broadcast timer uses dw-apb-ictl as
> > > > > interrupt chip, this patch adds irq_set_affinity support so that the
> > > > > going to deep idle state cpu can set the interrupt affinity of the
> > > > > broadcast interrupt to avoid unnecessary wakeups and IPIs.
> > > >
> > > > NAK to this patch.
> > > >
> > > > The real question is - if CPU0 is the CPU going offline, why is it
> > > > still receiving _any_ interrupts - all interrupts should be migrated
> > > > off it, including the chained interrupts.
> > >
> > > I think it's due to broadcast timer interrupt. Let me describe the situation:
> > >
> > > 1. cpu1 is going offline
> > > 2. cpuidle notify timer framework to use a broadcast timer instead due to localtimer
> > > is CLOCK_EVT_FEAT_C3STOP
> > > 3. when timer is expired, CPU0 will be waken up by the timer interrupt if it has
> > > gone offline
> > > 4. CPU0 sends broadcast timer IPI to CPU1
> >
> > If CPU1 is going offline, then CPU1 should have no interrupts delivered to
>
> "sleep $i" on CPU1 will make the timer framework to wake up it at current_time+$i
> in the future then go offline, currently this is achieved by programming one
> broadcast timer. In our case, the broadcast timer interrupt will be routed to
> CPU0 by default, so CPU0 has to send broadcast timer IPI to CPU1.
>
> > it. However, this is not the situation you're testing - in your results
> > below, and your "simple test" you never take CPU1 offline.
> >
>
> when cpu1 executes "sleep $i", cpu1 will go to deepest cpuidle level, in our
> case it will go offline.
>
I may misread your emails. I guess the "offline" means "cpu hot unplug"? Sorry
for misunderstanding.
This patch doesn't try to improve anything related with "hog unplug", it tries to
improve the following situation instead:
1. cpu1 is entering deepest cpuidle level, shutdown in our case.
2. cpuidle notify timer framework to use a broadcast timer instead due to localtimer
is CLOCK_EVT_FEAT_C3STOP
3. when timer is expired, CPU0 will be waken up by the timer interrupt if it has
been shutdown
4. CPU0 sends broadcast timer IPI to CPU1
Thanks,
Jisheng
next prev parent reply other threads:[~2015-07-04 9:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-04 5:19 [PATCH v2 0/2] irqchip: dw-apb-ictl: add irq_set_affinity support Jisheng Zhang
2015-07-04 5:19 ` [PATCH v2 1/2] irqchip: dw-apb-ictl: add private data structure Jisheng Zhang
2015-07-04 5:19 ` [PATCH v2 2/2] irqchip: dw-apb-ictl: add irq_set_affinity support Jisheng Zhang
2015-07-04 8:26 ` Russell King - ARM Linux
2015-07-04 8:50 ` Jisheng Zhang
2015-07-04 9:25 ` Russell King - ARM Linux
2015-07-04 9:35 ` Jisheng Zhang
2015-07-04 9:43 ` Jisheng Zhang [this message]
2015-07-04 9:53 ` Thomas Gleixner
2015-07-04 10:08 ` Russell King - ARM Linux
2015-07-04 10:33 ` Jisheng Zhang
2015-07-04 12:49 ` Thomas Gleixner
2015-07-04 13:16 ` Jisheng Zhang
2015-07-04 13:42 ` Thomas Gleixner
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=20150704174342.3fc8bd67@xhacker \
--to=jszhang@marvell.com \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).