Messages in this thread | | | Date | Tue, 1 Sep 2015 13:39:42 +0200 | From | Ingo Molnar <> | Subject | Re: [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
| |