[patch 2/8] Implement always-locked bit ops, for memory shared with an SMP hypervisor.

[patch 2/8] Implement always-locked bit ops, for memory shared with an SMP hypervisor.

Post by Jeremy Fit » Fri, 04 Aug 2006 09:40:06



You mean make the standard bit-ops atomic on UP when compiling for
CONFIG_PARAVIRT? We think its too much of a burden; there are only a
few operations which must be locked in the hypervisor case, and bit ops
are used everywhere. I'd like to get it to the point where there's no
significant overhead in configuring for PARAVIRT, even if you run on
native hardware.

J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[patch 2/8] Implement always-locked bit ops, for memory shared with an SMP hypervisor.

Post by Christoph » Fri, 04 Aug 2006 09:40:06


I think I asked this before....

Would it not be simpler to always use the locked implementation on UP? At
least when the kernel is compiled with hypervisor support? This is going
to add yet another series of bit operations.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

 
 
 

[patch 2/8] Implement always-locked bit ops, for memory shared with an SMP hypervisor.

Post by Christoph » Fri, 04 Aug 2006 10:10:11


Thats a good goal but what about the rest of us who have to maintain
additional forms of bit operations for all architectures. How much is this
burden? Are locked atomic bitops really that more expensive?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[patch 2/8] Implement always-locked bit ops, for memory shared with an SMP hypervisor.

Post by Zachary Am » Fri, 04 Aug 2006 10:20:05


It needn't be all architectures yet - only architectures that want to
compile Xen drivers are really affected. Perhaps a better place for
these locking primitives is in a Xen-specific driver header which
defines appropriate primitives for the architectures required? Last I
remember, there were still some issues here where atomic partial word
operations couldn't be supported on some architectures.

To answer your question, yes. On most i386 cores, locks destroy
performance, and even unintentional use of a single locked operation in
a critical path, on uncontended local memory, can have several hundred
cycles downstream penalty. I accidentally used one once during context
switch, and saw a 30% reduction in switch performance - on a modern
processor.

Zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[patch 2/8] Implement always-locked bit ops, for memory shared with an SMP hypervisor.

Post by Christoph » Fri, 04 Aug 2006 13:30:12


Those architectures that always use locked bitops or dont need them would
not need to be modified if we put this in a special fail. I think this is
a i386 speciality here?

Those operations are only needed for special xen driver and not for
regular kernel code!


asm-generic/xen-bitops.h asm-i386/xen-bitops.h is even less of a burden
and would only require a

#include <asm/xen-bitops.h>

for those special xen drivers.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[patch 2/8] Implement always-locked bit ops, for memory shared with an SMP hypervisor.

Post by Christoph » Fri, 04 Aug 2006 13:30:16


Thats not how it would be done. We would do this with
architecture specific xen files and a default in asm-generic.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[patch 2/8] Implement always-locked bit ops, for memory shared with an SMP hypervisor.

Post by Christoph » Fri, 04 Aug 2006 14:40:10


I still wonder why you are so focused on ifdefs. Why would we need those?


Maybe the best thing would be to have proper atomic ops in UP mode on
i386? The current way of just dropping the lock bit is the source of the
troubles.


But we all try to contain them. Here we have i386 hacks multiplying
all over the system.


Just adding a single line #include <asm/xen-bitops.h> to drivers that need
this functionality is not an undue burden for the drivers that support
Xen. They have to use special _xxx bitops anyways.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[patch 2/8] Implement always-locked bit ops, for memory shared with an SMP hypervisor.

Post by Christoph » Fri, 04 Aug 2006 15:00:08


No they would just need to do an #include <xen-bitops.h>


I understand but why dont we use regular ops explicitly
instead of hacking the atomic ops. Then we would not have unhack them now.


Could we not just add one fallback definition to asm-generic?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[patch 2/8] Implement always-locked bit ops, for memory shared with an SMP hypervisor.

Post by Christoph » Sat, 05 Aug 2006 02:00:10


An include <asm/xen-bitops.h> would need to fall back to asm-generic if
there is no file in asm-arch/xen-bitops.h. I thought we had such a
mechanism?


No. Into asm-generic/xen-bitops.h.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[patch 2/8] Implement always-locked bit ops, for memory shared with an SMP hypervisor.

Post by Christoph » Sat, 05 Aug 2006 11:20:09


Hmm... Well then we have no way of adding a new asm-arch file
without adding them to each arch. Makes it difficult to add
new functionality.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/