On 02/20/2013 11:22 PM, Borislav Petkov wrote:
> On Wed, Feb 20, 2013 at 10:20:19PM +0800, Alex Shi wrote:
>>>> > >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>>>> > >> index 2e8131d..0047856 100644
>>>> > >> --- a/kernel/sched/fair.c
>>>> > >> +++ b/kernel/sched/fair.c
>>>> > >> @@ -4053,6 +4053,8 @@ struct lb_env {
>>>> > >> unsigned int loop;
>>>> > >> unsigned int loop_break;
>>>> > >> unsigned int loop_max;
>>>> > >> + int power_lb; /* if power balance needed */
>>>> > >> + int perf_lb; /* if performance balance
>>>> > >> needed */
>>> > >
>>> > > Those look like they're used like simple boolean flags. Why not make
>>> > > them such, i.e. bitfields? See struct perf_event_attr for an example.
>> >
>> > there are 11 long words in struct lb_env now. use boolean or bitfields
>> > can't save much space.
> Now now maybe.
>
> Btw, there's a ->flags variable there which simply cries to get another
> LBF_* flag or two. This way you don't add any new members at all and
> don't enlarge the struct.
>
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?
--
Thanks Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
