From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [patch 0/7] tick: Optimize broadcast handling and prevent expiry ping pong
Date: Wed, 13 Mar 2013 15:05:16 +0530 [thread overview]
Message-ID: <51404854.8030303@ti.com> (raw)
In-Reply-To: <20130306111351.883117670@linutronix.de>
Thomas,
On Wednesday 06 March 2013 04:48 PM, Thomas Gleixner wrote:
> Jason decoded a problem related to the broadcast timer mode. The
> reprogramming of the cpu local timer causes a huge number of
> retries. Also there is a situation where the CPU which does not handle
> the broadcast timer interrupt exits and reenters broadcast mode before
> the broadcast interrupt got handled by another CPU. This can lead to
> an interesting ping pong of the broadcast and the cpu local timer
> code.
>
> This series addresses these problems. The first two patches convert
> the broadcast code to proper cpumask_var_t instead of adding more
> bitmaps later.
>
> The rest of the series is adopted from the quick patches which I
> posted earlier while discussing the issue with Jason et. al.
>
> Please give it a proper testing on your affected hardware.
>
I have tested this revised patches on OMAP4 and OMAP5 platforms
with CPUidle enabled against 3.9-rc2. As expected they seems to
work without any issue and also fixes the reported retry issue.
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
WARNING: multiple messages have this Message-ID (diff)
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
LAK <linux-arm-kernel@lists.infradead.org>,
John Stultz <john.stultz@linaro.org>,
Arjan van de Veen <arjan@infradead.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Jason Liu <liu.h.jason@gmail.com>
Subject: Re: [patch 0/7] tick: Optimize broadcast handling and prevent expiry ping pong
Date: Wed, 13 Mar 2013 15:05:16 +0530 [thread overview]
Message-ID: <51404854.8030303@ti.com> (raw)
In-Reply-To: <20130306111351.883117670@linutronix.de>
Thomas,
On Wednesday 06 March 2013 04:48 PM, Thomas Gleixner wrote:
> Jason decoded a problem related to the broadcast timer mode. The
> reprogramming of the cpu local timer causes a huge number of
> retries. Also there is a situation where the CPU which does not handle
> the broadcast timer interrupt exits and reenters broadcast mode before
> the broadcast interrupt got handled by another CPU. This can lead to
> an interesting ping pong of the broadcast and the cpu local timer
> code.
>
> This series addresses these problems. The first two patches convert
> the broadcast code to proper cpumask_var_t instead of adding more
> bitmaps later.
>
> The rest of the series is adopted from the quick patches which I
> posted earlier while discussing the issue with Jason et. al.
>
> Please give it a proper testing on your affected hardware.
>
I have tested this revised patches on OMAP4 and OMAP5 platforms
with CPUidle enabled against 3.9-rc2. As expected they seems to
work without any issue and also fixes the reported retry issue.
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
next prev parent reply other threads:[~2013-03-13 9:35 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-06 11:18 [patch 0/7] tick: Optimize broadcast handling and prevent expiry ping pong Thomas Gleixner
2013-03-06 11:18 ` Thomas Gleixner
2013-03-06 11:18 ` [patch 1/7] tick: Call tick_init late Thomas Gleixner
2013-03-06 11:18 ` Thomas Gleixner
2013-03-07 16:29 ` [tip:timers/core] " tip-bot for Thomas Gleixner
2013-03-06 11:18 ` [patch 2/7] tick: Convert broadcast cpu bitmaps to cpumask_var_t Thomas Gleixner
2013-03-06 11:18 ` Thomas Gleixner
2013-03-07 5:51 ` Rusty Russell
2013-03-07 5:51 ` Rusty Russell
2013-03-07 16:30 ` [tip:timers/core] " tip-bot for Thomas Gleixner
2013-03-06 11:18 ` [patch 3/7] tick: Avoid programming the local cpu timer if broadcast pending Thomas Gleixner
2013-03-06 11:18 ` Thomas Gleixner
2013-03-19 11:35 ` [tip:timers/core] " tip-bot for Thomas Gleixner
2013-03-06 11:18 ` [patch 4/7] tick: Handle broadcast wakeup of multiple cpus Thomas Gleixner
2013-03-06 11:18 ` Thomas Gleixner
2013-03-13 11:36 ` Lorenzo Pieralisi
2013-03-13 11:36 ` Lorenzo Pieralisi
2013-03-13 21:42 ` Thomas Gleixner
2013-03-13 21:42 ` Thomas Gleixner
2013-03-19 11:37 ` [tip:timers/core] " tip-bot for Thomas Gleixner
2013-03-06 11:18 ` [patch 5/7] tick: Provide a check for a forced broadcast pending Thomas Gleixner
2013-03-06 11:18 ` Thomas Gleixner
2013-03-19 11:38 ` [tip:timers/core] " tip-bot for Thomas Gleixner
2013-03-06 11:18 ` [patch 6/7] arm: Use tick broadcast expired check Thomas Gleixner
2013-03-06 11:18 ` Thomas Gleixner
2013-03-19 11:39 ` [tip:timers/core] " tip-bot for Thomas Gleixner
2013-03-06 11:18 ` [patch 7/7] x86: " Thomas Gleixner
2013-03-06 11:18 ` Thomas Gleixner
2013-03-19 11:40 ` [tip:timers/core] " tip-bot for Thomas Gleixner
2013-03-13 9:35 ` Santosh Shilimkar [this message]
2013-03-13 9:35 ` [patch 0/7] tick: Optimize broadcast handling and prevent expiry ping pong Santosh Shilimkar
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=51404854.8030303@ti.com \
--to=santosh.shilimkar@ti.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 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.