lkml.org 
[lkml]   [2013]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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


    \
     
     \ /
      Last update: 2013-02-21 16:21    [W:3.983 / U:0.148 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site