lkml.org 
[lkml]   [2015]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/2] x86/bitops: implement __test_bit

* Michael S. Tsirkin <mst@redhat.com> wrote:

> On Tue, Sep 01, 2015 at 11:24:22AM +0200, Ingo Molnar wrote:
> >
> > * Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > > I applied this patch on top of mine:
> >
> > Yeah, looks similar to the one I sent.
> >
> > > -static inline int __variable_test_bit(long nr, const unsigned long *addr)
> > > -{
> > > - int oldbit;
> > > -
> > > - asm volatile("bt %2,%1\n\t"
> > > - "sbb %0,%0"
> > > - : "=r" (oldbit)
> > > - : "m" (*addr), "Ir" (nr));
> > > -
> > > - return oldbit;
> > > -}
> >
> > > And the code size went up:
> > >
> > > 134836 2997 8372 146205 23b1d arch/x86/kvm/kvm-intel.ko ->
> > > 134846 2997 8372 146215 23b27 arch/x86/kvm/kvm-intel.ko
> > >
> > > 342690 47640 441 390771 5f673 arch/x86/kvm/kvm.ko ->
> > > 342738 47640 441 390819 5f6a3 arch/x86/kvm/kvm.ko
> > >
> > > I tried removing __always_inline, this had no effect.
> >
> > But code size isn't the only factor.
> >
> > Uros Bizjak pointed out that the reason GCC does not use the "BT reg,mem"
> > instruction is that it's highly suboptimal even on recent microarchitectures,
> > Sandy Bridge is listed as having a 10 cycles latency (!) for this instruction:
> >
> > http://www.agner.org/optimize/instruction_tables.pdf
> >
> > this instruction had bad latency going back to Pentium 4 CPUs.
> >
> > ... so unless something changed in this area with Skylake I think using the
> > __variable_test_bit() code of the kernel is a bad choice and looking at kernel
> > size only is misleading.
> >
> > It makes sense for atomics, but not for unlocked access.
> >
> > Thanks,
> >
> > Ingo
>
> Hmm - so do you take back the ack?

I have no strong feelings either way, it simply strikes me as misguided to
explicitly optimize for something that is listed as a high overhead instruction.

Assuming it really is high overhead:

> I compared this:
> int main(int argc, char **argv)
> {
>
> long long int i;
> const unsigned long addr = 0;
> for (i = 0; i < 1000000000ull; ++i) {
> asm volatile("");
> if (__variable_test_bit(1, &addr))
> asm volatile("");
> }
> return 0;
> }
>
> with the __constant_test_bit variant.
>
> __constant_test_bit code does appear to be slower on an i7 processor.

Hm, so this seems to be contradictory: if I'm right with the argument above then
we'd expect the opposite result: variable_test_bit (BT using asm variant) should
be slower than constant_test_bit (GCC version), correct?

Btw., to be sure it's a representative performance test instead of a barrier() in
your testcase I'd actually do something with the result in a way neither the
compiler nor the CPU can optimize it out as unused.

> test_bit isn't atomic either. Maybe drop variable_test_bit there too?

Yes, but only if I'm right about BT being suboptimal in this case on modern x86
CPUs!

Thanks,

Ingo


\
 
 \ /
  Last update: 2015-09-01 14:01    [W:0.191 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site