On 09/01/2015 08:03 AM, Michael S. Tsirkin wrote:
>>>
>>> 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.
>>
>
> [mst@robin test]$ diff a.c
On Tue, Sep 01, 2015 at 01:39:42PM +0200, Ingo Molnar wrote:
>
> * Michael S. Tsirkin wrote:
>
> > On Tue, Sep 01, 2015 at 11:24:22AM +0200, Ingo Molnar wrote:
> > >
> > > * Michael S. Tsirkin wrote:
> > >
> > > > I applied this patch on top of mine:
> > >
> > > Yeah, looks similar to the
* Michael S. Tsirkin wrote:
> On Tue, Sep 01, 2015 at 11:24:22AM +0200, Ingo Molnar wrote:
> >
> > * Michael S. Tsirkin 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
On Tue, Sep 01, 2015 at 11:24:22AM +0200, Ingo Molnar wrote:
>
> * Michael S. Tsirkin 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;
> > -
* Michael S. Tsirkin 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"
> -
On 09/01/2015 08:03 AM, Michael S. Tsirkin wrote:
>>>
>>> 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.
>>
>
> [mst@robin test]$ diff a.c
On Tue, Sep 01, 2015 at 11:24:22AM +0200, Ingo Molnar wrote:
>
> * Michael S. Tsirkin 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)
> > -{
> > -
* Michael S. Tsirkin 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
* Michael S. Tsirkin wrote:
> On Tue, Sep 01, 2015 at 11:24:22AM +0200, Ingo Molnar wrote:
> >
> > * Michael S. Tsirkin wrote:
> >
> > > I applied this patch on top of mine:
> >
> > Yeah, looks similar to the one I sent.
> >
> > > -static inline int
On Tue, Sep 01, 2015 at 01:39:42PM +0200, Ingo Molnar wrote:
>
> * Michael S. Tsirkin wrote:
>
> > On Tue, Sep 01, 2015 at 11:24:22AM +0200, Ingo Molnar wrote:
> > >
> > > * Michael S. Tsirkin wrote:
> > >
> > > > I applied this patch on top of mine:
> > >
On Mon, Aug 31, 2015 at 09:59:47AM +0200, Ingo Molnar wrote:
>
> * Michael S. Tsirkin wrote:
>
> > On Sun, Aug 30, 2015 at 11:13:20PM -0700, H. Peter Anvin wrote:
> > > Presumably because gcc can't generate bt... whether or not it is worth it
> > > is another matter.
> > >
> > > On August 30,
* yalin wang wrote:
>
> > On Aug 31, 2015, at 15:59, Ingo Molnar wrote:
> >
> >
> > * Michael S. Tsirkin wrote:
> >
> >> On Sun, Aug 30, 2015 at 11:13:20PM -0700, H. Peter Anvin wrote:
> >>> Presumably because gcc can't generate bt... whether or not it is worth it
> >>> is another
> On Aug 31, 2015, at 15:59, Ingo Molnar wrote:
>
>
> * Michael S. Tsirkin wrote:
>
>> On Sun, Aug 30, 2015 at 11:13:20PM -0700, H. Peter Anvin wrote:
>>> Presumably because gcc can't generate bt... whether or not it is worth it
>>> is another matter.
>>>
>>> On August 30, 2015 11:05:49 PM
* Ingo Molnar wrote:
> > Disassembly of section .text:
> >
> > <__variable_test_bit>:
> > __variable_test_bit():
> >0: 8b 54 24 08 mov0x8(%esp),%edx
> >4: 8b 44 24 04 mov0x4(%esp),%eax
> >8: 0f a3 02bt %eax,(%edx)
>
* Michael S. Tsirkin wrote:
> On Sun, Aug 30, 2015 at 11:13:20PM -0700, H. Peter Anvin wrote:
> > Presumably because gcc can't generate bt... whether or not it is worth it
> > is another matter.
> >
> > On August 30, 2015 11:05:49 PM PDT, Ingo Molnar wrote:
> > >
> > >* Michael S. Tsirkin
On Sun, Aug 30, 2015 at 11:13:20PM -0700, H. Peter Anvin wrote:
> Presumably because gcc can't generate bt... whether or not it is worth it is
> another matter.
>
> On August 30, 2015 11:05:49 PM PDT, Ingo Molnar wrote:
> >
> >* Michael S. Tsirkin wrote:
> >
> >> +static __always_inline int
Presumably because gcc can't generate bt... whether or not it is worth it is
another matter.
On August 30, 2015 11:05:49 PM PDT, Ingo Molnar wrote:
>
>* Michael S. Tsirkin wrote:
>
>> +static __always_inline int __constant_test_bit(long nr, const
>unsigned long *addr)
>> +{
>> +return
* Michael S. Tsirkin wrote:
> +static __always_inline int __constant_test_bit(long nr, const unsigned long
> *addr)
> +{
> + return ((1UL << (nr & (BITS_PER_LONG-1))) &
> + (addr[nr >> _BITOPS_LONG_SHIFT])) != 0;
> +}
> +
> +static inline int __variable_test_bit(long nr, const
* Michael S. Tsirkin wrote:
> +static __always_inline int __constant_test_bit(long nr, const unsigned long
> *addr)
> +{
> + return ((1UL << (nr & (BITS_PER_LONG-1))) &
> + (addr[nr >> _BITOPS_LONG_SHIFT])) != 0;
> +}
> +
> +static inline int
Presumably because gcc can't generate bt... whether or not it is worth it is
another matter.
On August 30, 2015 11:05:49 PM PDT, Ingo Molnar wrote:
>
>* Michael S. Tsirkin wrote:
>
>> +static __always_inline int __constant_test_bit(long nr, const
>unsigned
On Sun, Aug 30, 2015 at 11:13:20PM -0700, H. Peter Anvin wrote:
> Presumably because gcc can't generate bt... whether or not it is worth it is
> another matter.
>
> On August 30, 2015 11:05:49 PM PDT, Ingo Molnar wrote:
> >
> >* Michael S. Tsirkin wrote:
> >
> On Aug 31, 2015, at 15:59, Ingo Molnar wrote:
>
>
> * Michael S. Tsirkin wrote:
>
>> On Sun, Aug 30, 2015 at 11:13:20PM -0700, H. Peter Anvin wrote:
>>> Presumably because gcc can't generate bt... whether or not it is worth it
>>> is another matter.
>>>
* Ingo Molnar wrote:
> > Disassembly of section .text:
> >
> > <__variable_test_bit>:
> > __variable_test_bit():
> >0: 8b 54 24 08 mov0x8(%esp),%edx
> >4: 8b 44 24 04 mov0x4(%esp),%eax
> >8: 0f a3 02bt
* yalin wang wrote:
>
> > On Aug 31, 2015, at 15:59, Ingo Molnar wrote:
> >
> >
> > * Michael S. Tsirkin wrote:
> >
> >> On Sun, Aug 30, 2015 at 11:13:20PM -0700, H. Peter Anvin wrote:
> >>> Presumably because gcc can't generate
On Mon, Aug 31, 2015 at 09:59:47AM +0200, Ingo Molnar wrote:
>
> * Michael S. Tsirkin wrote:
>
> > On Sun, Aug 30, 2015 at 11:13:20PM -0700, H. Peter Anvin wrote:
> > > Presumably because gcc can't generate bt... whether or not it is worth it
> > > is another matter.
> > >
>
* Michael S. Tsirkin wrote:
> On Sun, Aug 30, 2015 at 11:13:20PM -0700, H. Peter Anvin wrote:
> > Presumably because gcc can't generate bt... whether or not it is worth it
> > is another matter.
> >
> > On August 30, 2015 11:05:49 PM PDT, Ingo Molnar wrote:
One little known side effect of test_bit is that it adds
a kind of a compiler barrier since the pointer parameter
is volatile.
It seems risky to change the semantics of test_bit so let's just
add __test_bit (matching __set_bit and __clear_bit) that does
not add such a barrier.
Will be used by
One little known side effect of test_bit is that it adds
a kind of a compiler barrier since the pointer parameter
is volatile.
It seems risky to change the semantics of test_bit so let's just
add __test_bit (matching __set_bit and __clear_bit) that does
not add such a barrier.
Will be used by
28 matches
Mail list logo