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:   Tue, 2 Apr 2019 21:36:42 -0500
From:   Yang Li <pku.leo@...il.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Russell King - ARM Linux <linux@....linux.org.uk>,
        "mark.rutland@....com" <mark.rutland@....com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Arnd Bergmann <arnd@...db.de>,
        Huan Wang <alison.wang@...escale.com>,
        Huan Wang <alison.wang@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        John Stultz <john.stultz@...aro.org>,
        LAK <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] arm: kernel: utilize hrtimer based broadcast

On Tue, Jan 5, 2016 at 3:46 AM Thomas Gleixner <tglx@...utronix.de> wrote:
>
> On Sat, 2 Jan 2016, Russell King - ARM Linux wrote:
> > On Tue, Dec 29, 2015 at 02:54:10PM +0100, Thomas Gleixner wrote:
> > > I have no real opinion about that patch. It does no harm to unconditionally
> > > setup the hrtimer based broadcast even if it's never used.
> > >
> > > Up to the arch maintainer to decide.
> >
> > That's really not fair to keep shovelling these kinds of decisions onto
> > architecture maintainers without any kind of explanation about how an
> > architecture maintainer should make such a decision.
> >
> > Do I roll a 6-face dice, and if it gives an odd number, I apply this
> > patch, otherwise I reject it?
> >
> > Is there a technical basis for making the decision?  If so, please
> > explain what the technical arguments are against having or not having
> > this change.
>
> The hrtimer based broadcast device is used when you have per cpu timers which
> stop in deeper power states, but you have no other timer hardware on the chip
> which can backup the per cpu timer in deep power states. The trick is that it
> emulates a timer hardware via a hrtimer and then tells the cpu idle code not
> to go into deep power states on the cpu which owns that hrtimer. All other
> cpus can go as deep as they want and still get woken up.
>
> The only downside of adding this unconditionally is extra code in case that it
> is not needed on a particular platform.
>
> Hope that helps.

Hi Russell,

This has been pending for so long time.  I assume this is an ack from
Thomas.  And given the same thing has been added for arm64 and powerpc
architecture, can you also merge this for ARM?


Regards,
Leo

Powered by blists - more mailing lists