All of lore.kernel.org
 help / color / mirror / Atom feed
From: leoy@marvell.com (Leo Yan)
To: linux-arm-kernel@lists.infradead.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

WARNING: multiple messages have this Message-ID (diff)
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:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-19  5:31 Leo Yan [this message]
2014-08-19  5:31 ` [Question]: redundant interrupts for broadcast timer Leo Yan

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=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.