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

Groups > linux.kernel > #1739076 > unrolled thread

Re: [PATCH 07/25] hrtimer: Reduce conditional code (hres_active)

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 07/25] hrtimer: Reduce conditional code (hres_active) Peter Zijlstra <peterz@infradead.org> - 2017-09-25 16:00 +0200
    Re: [PATCH 07/25] hrtimer: Reduce conditional code (hres_active) Thomas Gleixner <tglx@linutronix.de> - 2017-09-25 16:30 +0200

#1739076 — Re: [PATCH 07/25] hrtimer: Reduce conditional code (hres_active)

On Thu, Aug 31, 2017 at 12:23:36PM -0000, Anna-Maria Gleixner wrote:
> The hrtimer_cpu_base struct has the CONFIG_HIGH_RES_TIMERS conditional
> struct member hres_active. All related functions to this member are
> conditional as well.
> 
> There is no functional change, when the hres_active member is unconditional
> with all related functions and is set to zero during initialization. This
> makes the code easier to read.

But you make what was a compile time dead-code-elimination into a
runtime load-and-branch.

Unless the compiler is overly clever and is able to deduce from the lack
of assignments that it must always be 0, is it?

[toc] | [next] | [standalone]

#1739088

On Mon, 25 Sep 2017, Peter Zijlstra wrote:
> On Thu, Aug 31, 2017 at 12:23:36PM -0000, Anna-Maria Gleixner wrote:
> > The hrtimer_cpu_base struct has the CONFIG_HIGH_RES_TIMERS conditional
> > struct member hres_active. All related functions to this member are
> > conditional as well.
> > 
> > There is no functional change, when the hres_active member is unconditional
> > with all related functions and is set to zero during initialization. This
> > makes the code easier to read.
> 
> But you make what was a compile time dead-code-elimination into a
> runtime load-and-branch.
> 
> Unless the compiler is overly clever and is able to deduce from the lack
> of assignments that it must always be 0, is it?

Probably not. So the simple way to solve this is to make the new common

is_highres_active()
{
	return IS_ENABLED(CONFIG_HIGH_RES) ? base->hres_active : 0;
}

Thanks,

	tglx

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web