linux-kernel - RE: [PATCH] hrtimer:do not start hrtimer on other cpu if it is the leftmost timer.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 30 Apr 2014 12:29:20 +0000
From:	"Ma, Xindong" <xindong.ma@...el.com>
To:	Viresh Kumar <viresh.kumar@...aro.org>
CC:	Thomas Gleixner <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] hrtimer:do not start hrtimer on other cpu if it is the
 leftmost timer.


> -----Original Message-----
> From: viresh.linux@...il.com [mailto:viresh.linux@...il.com] On Behalf Of
> Viresh Kumar
> Sent: Wednesday, April 30, 2014 6:36 PM
> To: Ma, Xindong
> Cc: Thomas Gleixner; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH] hrtimer:do not start hrtimer on other cpu if it is the
> leftmost timer.
> 
> Hi Leon,
> 
> On Wed, Apr 30, 2014 at 2:13 PM, Leon Ma <xindong.ma@...el.com> wrote:
> > On SMP system, if cpuX is idle and it starts an hrtimer, the timer
> > will be started on cpuY. But it can not reprogram the event source on
> > cpuY. The timer is inserted into rb tree of cpuY, if it is the
> > leftmost timer on cpuY and it is a very short timer, following
> > hrtimers started on cpuY will also not set the event source. As a
> > result, the timers on cpuY will expire later than expected.
> 
> Don't know but the explanation confused me a bit :), thought the patch looked
> fine. So, in my words this is what I understood, let me know if I am on the right
> side.
> 
> Current base of timer is: cpuY and we started timer from cpuX. If cpuX is idle,
> we might select cpuY again as the base but we wouldn't be able to reprogram
> the event source as it has to be done by local CPU.
> 
> And so in this case you want to select cpuX instead, right?
Yes. Thanks Thomas to refine the changelog and make it clear:
http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=012a45e3f4af68e86d85cce060c6c2fed56498b2
> 
> > When this case is detected, we should start the timer on cpuX and
> > program event source properly.
> >
> > Signed-off-by: Leon Ma <xindong.ma@...el.com>
> > ---
> >  kernel/hrtimer.c |    5 +++++
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c index
> > d55092c..68becbc 100644
> > --- a/kernel/hrtimer.c
> > +++ b/kernel/hrtimer.c
> > @@ -234,6 +234,11 @@ again:
> >                         goto again;
> >                 }
> >                 timer->base = new_base;
> > +       } else {
> > +               if (cpu != this_cpu && hrtimer_check_target(timer,
> new_base)) {
> > +                       cpu = this_cpu;
> > +                       goto again;
> > +               }
> >         }
> >         return new_base;
> >  }
> > --
> > 1.7.9.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-kernel" in the body of a message to majordomo@...r.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/