Re: [patch v5 11/15] sched: add power/performance balance allow flag

From: Alex Shi <alex.shi@intel.com>
To: Borislav Petkov <bp@alien8.de>,
	torvalds@linux-foundation.org, mingo@redhat.com,
	peterz@infradead.org, tglx@linutronix.de,
	akpm@linux-foundation.org, arjan@linux.intel.com, pjt@google.com,
	namhyung@kernel.org, efault@gmx.de, vincent.guittot@linaro.org,
	gregkh@linuxfoundation.org, preeti@linux.vnet.ibm.com,
	viresh.kumar@linaro.org, linux-kernel@vger.kernel.org,
	morten.rasmussen@arm.com
Subject: Re: [patch v5 11/15] sched: add power/performance balance allow flag
Date: Thu, 21 Feb 2013 22:52:33 +0800	[thread overview]
Message-ID: <512634B1.4040101@intel.com> (raw)
In-Reply-To: <20130221094213.GA4694@pd.tnic>

On 02/21/2013 05:42 PM, Borislav Petkov wrote:
> On Thu, Feb 21, 2013 at 09:32:54AM +0800, Alex Shi wrote:
>> Yes, use flags can save 2 int variable, I will change that.
>>
>> Just curious, consider the lb_env size and just used in stack, plus
>> the big cacheline size of modern cpu, and the alignment of gcc flag on
>> kernel, seems no arch needs more cache lines. Are there any platforms
>> performance is impacted by this 2 int variables?
> 
> Not that I know of. But that's not the point: if we don't pay attention
> and are not as economical as possible in the kernel, and especially in
> heavily walked code as the scheduler, we'll become fat and bloated (if
> we're not halfway there already, that is).
> 
> It might not impact processor bandwidth now because internal paths are
> obviously adequate but you're not the only one adding features. What
> happens if the next guy comes and adds another two integers just because
> it is convenient in the code?

Thanks for the detailed nice explanation!

I know the point, as a performance sensitive guy, just curious which
platform maybe impacted. :)
> 
> Btw, sizeof(lb_env) is currently something around 80 bytes AFAICT. Now
> that doesn't fit in one cacheline anyway. So if you add your two ints,
> they'll be trailing in the second cacheline which needs to go up to L1.
> 
> Now flags will still be at the beginning of the second cacheline but
> it is still better to add two new bits there because this is exactly
> what this variable is for.
> 
> And, just for the fun of it, if you push the flags variable higher in
> the struct itself, it will land in the first cacheline and there's your
> design with *absolutely* no overhead in that respect. I betcha if you
> do this, you won't see any overhead in L1 utilization even with perf
> counters because you get it practically for free.

thanks suggestion.
looks the member's sequence was considered in lb_env. The 'flags' looks
less important and used frequent than the fields before it. :)
> 
> :-)
> 

-- 
Thanks
    Alex