Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1300054 > unrolled thread

Re: [PATCH] arm: kernel: utilize hrtimer based broadcast

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] arm: kernel: utilize hrtimer based broadcast Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-01-02 11:40 +0100
    Re: [PATCH] arm: kernel: utilize hrtimer based broadcast Thomas Gleixner <tglx@linutronix.de> - 2016-01-05 10:50 +0100

#1300054 — Re: [PATCH] arm: kernel: utilize hrtimer based broadcast

On Tue, Dec 29, 2015 at 02:54:10PM +0100, Thomas Gleixner wrote:
> On Mon, 28 Dec 2015, Arnd Bergmann wrote:
> 
> > On Monday 28 December 2015 07:18:58 Huan Wang wrote:
> > > Hi, Arnd,
> > > 
> > > 	Could you help to review the following patch? Thanks.
> > > 
> > 
> > Hi Alison,
> > 
> > I'm sorry but I understand very little of this particular area of the kernel.
> > 
> > I've added Daniel Lezcano, John Stultz and Thomas Gleixner to Cc, they all
> > know this much better than I do and one of them should be able to comment after
> > their Christmas break.
> 
> 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.

Thanks.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1301381

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.

     tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web