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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 21 Feb 2013 10:42:13 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Alex Shi <alex.shi@...el.com>
Cc:	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 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?

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.

:-)

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/