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

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 21 Feb 2013 22:52:33 +0800
From:	Alex Shi <alex.shi@...el.com>
To:	Borislav Petkov <bp@...en8.de>, torvalds@...ux-foundation.org,
	mingo@...hat.com, peterz@...radead.org, tglx@...utronix.de,
	akpm@...ux-foundation.org, arjan@...ux.intel.com, pjt@...gle.com,
	namhyung@...nel.org, efault@....de, vincent.guittot@...aro.org,
	gregkh@...uxfoundation.org, preeti@...ux.vnet.ibm.com,
	viresh.kumar@...aro.org, linux-kernel@...r.kernel.org,
	morten.rasmussen@....com
Subject: Re: [patch v5 11/15] sched: add power/performance balance allow flag

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
--
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/