My turn to rant about types... bitops

My turn to rant about types... bitops

[Jimi Xenidis]

I think around linux-2.4.19 (and thanks to rusty?) bitops.h went s/ 
void */unsigned long */, any chance is Xen following suit?
The next request would be to change all arrays destined for bitops to  
be defined using unsigned long.
specifically:
     struct shared_info {
         [....]
         u32 evtchn_pending[32];
         u32 evtchn_mask[32];
     };

-JX

Re: My turn to rant about types... bitops

[Keir Fraser]

On 5 Oct 2005, at 17:52, Jimi Xenidis wrote:

> I think around linux-2.4.19 (and thanks to rusty?) bitops.h went 
> s/void */unsigned long */, any chance is Xen following suit?
> The next request would be to change all arrays destined for bitops to 
> be defined using unsigned long.
> specifically:

Just cast to 'unsigned long *' when you use those ops. Why work around 
details of the way that Linux happens to do atomic ops in our 
interfaces?

  -- Keir

Re: My turn to rant about types... bitops

[Jimi Xenidis]

Always the job of the maintainer to ask why :)
Well, since linux bitops use unsigned long, being the largest machine  
word and therefore the most efficient, we get alignment issues.

The next request is really the jist of what we are after, doing 64bit  
operations 32bit aligned data kills us performance wise and WRT  
bitops cannot be used for atomic ops. If htis was just Xen I'd  
consider adding 32bit bitops but I doubt I'd be able to do that in  
Linux which does not provide "u32" bitops.

IIRC assuring this alignement would even help x86, no?
-JX

On Oct 5, 2005, at 2:17 PM, Keir Fraser wrote:


>
> On 5 Oct 2005, at 17:52, Jimi Xenidis wrote:
>
>
>
>> I think around linux-2.4.19 (and thanks to rusty?) bitops.h went s/ 
>> void */unsigned long */, any chance is Xen following suit?
>> The next request would be to change all arrays destined for bitops  
>> to be defined using unsigned long.
>> specifically:
>>
>>
>
> Just cast to 'unsigned long *' when you use those ops. Why work  
> around details of the way that Linux happens to do atomic ops in  
> our interfaces?
>
>  -- Keir
>
>
>
>

-JX
--
"I got an idea, an idea so smart my head would explode if I even
   began to know what I was talking about." -- Peter Griffin (Family  
Guy)

Re: My turn to rant about types... bitops

[Keir Fraser]

On 6 Oct 2005, at 12:28, Jimi Xenidis wrote:

> Always the job of the maintainer to ask why :)
> Well, since linux bitops use unsigned long, being the largest machine 
> word and therefore the most efficient, we get alignment issues.
>
> The next request is really the jist of what we are after, doing 64bit 
> operations 32bit aligned data kills us performance wise and WRT bitops 
> cannot be used for atomic ops. If htis was just Xen I'd consider 
> adding 32bit bitops but I doubt I'd be able to do that in Linux which 
> does not provide "u32" bitops.

The alignment issue is a fair point. I'll see if changing the type 
would affect much code.

  -- Keir

Re: My turn to rant about types... bitops

[Andi Kleen]

Jimi Xenidis <jimix@watson.ibm.com> writes:
> 
> The next request is really the jist of what we are after, doing 64bit
> operations 32bit aligned data kills us performance wise and WRT
> bitops cannot be used for atomic ops. If htis was just Xen I'd
> consider adding 32bit bitops but I doubt I'd be able to do that in
> Linux which does not provide "u32" bitops.

Actually it does - when the arch has ARCH_HAS_ATOMIC_UNSIGNED set
it's allowed with the normal bitops.
 
> IIRC assuring this alignement would even help x86, no?

I doubt it (unless you're straddling a cache line) 

-Andi

Re: My turn to rant about types... bitops

[Jimi Xenidis]

On Oct 6, 2005, at 9:39 AM, Andi Kleen wrote:

> Jimi Xenidis <jimix@watson.ibm.com> writes:
>
>> adding 32bit bitops but I doubt I'd be able to do that in
>> Linux which does not provide "u32" bitops.
>>
>
> Actually it does - when the arch has ARCH_HAS_ATOMIC_UNSIGNED set
> it's allowed with the normal bitops.
Its not set for linuxppc64, bitops use longs so the code is optimized  
for them.


-JX
--
"I got an idea, an idea so smart my head would explode if I even
   began to know what I was talking about." -- Peter Griffin (Family  
Guy)

Re: My turn to rant about types... bitops

[Andi Kleen]

On Thursday 06 October 2005 17:10, Jimi Xenidis wrote:
> On Oct 6, 2005, at 9:39 AM, Andi Kleen wrote:
> > Jimi Xenidis <jimix@watson.ibm.com> writes:
> >> adding 32bit bitops but I doubt I'd be able to do that in
> >> Linux which does not provide "u32" bitops.
> >
> > Actually it does - when the arch has ARCH_HAS_ATOMIC_UNSIGNED set
> > it's allowed with the normal bitops.
>
> Its not set for linuxppc64, bitops use longs so the code is optimized
> for them.

Well, that's a specific linuxppc64 limitation.

-Andi

Re: My turn to rant about types... bitops

[Rusty Russell]

On Wed, 2005-10-05 at 19:17 +0100, Keir Fraser wrote:
> On 5 Oct 2005, at 17:52, Jimi Xenidis wrote:
> 
> > I think around linux-2.4.19 (and thanks to rusty?) bitops.h went 
> > s/void */unsigned long */, any chance is Xen following suit?
> > The next request would be to change all arrays destined for bitops to 
> > be defined using unsigned long.
> > specifically:
> 
> Just cast to 'unsigned long *' when you use those ops. Why work around 
> details of the way that Linux happens to do atomic ops in our 
> interfaces?

A bitmask type might be nice.  Linux has some ugly macros to do just
that, but at least it's explicit ("need this many bits").

Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman