[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.0811262156390.3325@localhost.localdomain>
Date: Wed, 26 Nov 2008 22:18:09 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Andi Kleen <andi@...stfloor.org>
cc: eranian@...glemail.com, linux-kernel@...r.kernel.org,
akpm@...ux-foundation.org, mingo@...e.hu, x86@...nel.org,
eranian@...il.com, sfr@...b.auug.org.au
Subject: Re: [patch 05/24] perfmon: X86 generic code (x86)
On Wed, 26 Nov 2008, Andi Kleen wrote:
> On Wed, Nov 26, 2008 at 02:35:18PM +0100, Thomas Gleixner wrote:
> > > + * does not work with other types of PMU registers.Thus, no
> > > + * address is ever exposed by counters
> > > + *
> > > + * - there is never a dependency between one pmd register and
> > > + * another
> > > + */
> > > + for (i = 0; num; i++) {
> > > + if (likely(pfm_arch_bv_test_bit(i, set->used_pmds))) {
> > > + pfm_write_pmd(ctx, i, set->pmds[i]);
> > > + num--;
> > > + }
> > > + }
> >
> > This loop construct looks scary. It relies on set->nused_pmds >=
> > bits set in set->used_pmds. I had to look more than once to
> > understand that. It's used all over the code in variations.
>
> FWIW this loop style tripped me up during review too.
It's even worse than I thought when looking at it a second time:
All the loops iterate over an array which means in the worst case we
do full array_size iterations. In each iteration we check whether the
corresponding bit in the bitmask is set or not.
What a nonsense. We have a bitmask already. Why not iterate over the
bitmask and be done ?
Thanks,
tglx
--
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/
Powered by blists - more mailing lists