From: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Dave Jones <davej@redhat.com>,
tglx@linutronix.de
Subject: Re: [PATCH 1/2] Add support for deferrable timers
Date: Thu, 22 Mar 2007 05:18:17 -0700 [thread overview]
Message-ID: <20070322121816.GA15473@linux-os.sc.intel.com> (raw)
In-Reply-To: <20070322031826.55d483e4.akpm@linux-foundation.org>
On Thu, Mar 22, 2007 at 03:18:26AM -0800, Andrew Morton wrote:
> On Wed, 21 Mar 2007 13:22:17 -0700 Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> wrote:
>
> >
> > Introduce a new flag for timers - 'deferrable timer'
> > Timers that work normally when system is busy. But, will not cause CPU to
> > come out of idle (just to service this timer), when CPU is idle. Instead,
> > this timer will be serviced when CPU eventually wakes up with a subsequent
> > non-deferrable timer or any other event.
> >
> > The main advantage of this is to avoid unnecessary timer interrupts when
> > CPU is idle. If the routine currently called by a timer can wait until next
> > event without any issues, this new timer can be used while setting up timer
> > for that routine. This, with dynticks, allows CPUs to be lazy, allowing them
> > to stay in idle for extended period of time by reducing unnecesary wakeup and
> > thereby reducing the power consumption.
> >
> > This patch:
> > Builds this new timer on top of existing timer infrastructure. It uses
> > last bit in 'base' pointer of timer_list structure to store this
> > deferrable timer flag. __next_timer_interrupt() function
> > skips over these deferrable timers when CPU looks for
> > next timer event for which it has to wake up.
> >
> > This is exported by a new interface init_timer_deferrable() that can
> > be called in place of regular init_timer().
> >
>
> These patches cause a lockup during execuion of `halt -p'. See phuzzy foto
> at http://userweb.kernel.org/~akpm/s5000486.jpg
>
> It's fairly obvious why, when one looks at lock_timer_base().
Hmm.. Wonder how it worked for me and why I did not see this hang.
I had thought I covered all accesses to ->base. Obviously, I have missed
this "base == timer->base" check here. Will fix it and respin a patch later
today with below suggestions as well.
Thanks,
Venki
prev parent reply other threads:[~2007-03-22 12:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-21 20:22 [PATCH 1/2] Add support for deferrable timers Venkatesh Pallipadi
2007-03-22 11:18 ` Andrew Morton
2007-03-22 12:18 ` Venkatesh Pallipadi [this message]
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=20070322121816.GA15473@linux-os.sc.intel.com \
--to=venkatesh.pallipadi@intel.com \
--cc=akpm@linux-foundation.org \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/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.