public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Leo Yan <leoy@marvell.com>
To: Chao Xie <cxie4@marvell.com>, Leo Song <liangs@marvell.com>,
	Lu Mao <ylmao@marvell.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: [Question]: redundant interrupts for broadcast timer
Date: Tue, 19 Aug 2014 13:31:30 +0800	[thread overview]
Message-ID: <53F2E132.10701@marvell.com> (raw)

hi,

We observed the redundant interrupts for broadcast timer, so want to 
confirm here firstly; pls see below flow:

1. Thread_A starts a hrtimer with 100ms timeout, and then thread_A will 
remove from the runqueue to sleep;
2. The CPU which thread_A runs on will enter idle and call notify 
CLOCK_EVT_NOTIFY_BROADCAST_ENTER, so the CPU will shutdown its local 
timer and set broadcast timer's next event with delta for 100ms;
3. After 70ms later, the CPU is waken up by other peripheral's interrupt 
and thread_A will be waken up as well; thread_A will cancel the hrtimer 
at this point, kernel will remove the timer event from the event queue 
but it will not disable broadcast timer;
4. So after 30ms later, the broadcast timer interrupt will be triggered 
even though the timer has been cancelled by s/w in step 3.

With current timer framework, is upper behaviour expected? Or maybe we 
miss something so that introduce such kind issue?

And i'm interesting now if have some idea to optimize such issue, very 
appreciate for suggestion and comment.

Thanks,
Leo Yan

                 reply	other threads:[~2014-08-19  5:35 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=53F2E132.10701@marvell.com \
    --to=leoy@marvell.com \
    --cc=cxie4@marvell.com \
    --cc=liangs@marvell.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ylmao@marvell.com \
    /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