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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel