* Re: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
@ 2005-04-28 20:43 ` David Mosberger
2005-04-28 20:53 ` Christoph Lameter
` (22 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: David Mosberger @ 2005-04-28 20:43 UTC (permalink / raw)
To: linux-ia64
>>>>> On Thu, 28 Apr 2005 13:32:35 -0700 (PDT), Christoph Lameter <clameter@engr.sgi.com> said:
Christoph> #define _raw_write_unlock(x) \
Christoph> ({ \
Christoph> - smp_mb__before_clear_bit(); /* need barrier before releasing lock... */ \
Christoph> - clear_bit(31, (x)); \
Christoph> + u8 *y = (u8 *)x; \
Christoph> + smp_wmb(); /* need barrier before releasing lock... */ \
Christoph> + y[3] = 0; \
Christoph> })
I'm unsure if it's a good idea to reduce the counter size.
Independent of that: using a name like "y" in a macro is bound to
cause name collisions so it's a big no-no. Then why not declare
"y" as a "volatile u8 *" so you can avoid the explicit smp_wmb()?
This is ia64-specific code after all.
--david
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
2005-04-28 20:43 ` David Mosberger
@ 2005-04-28 20:53 ` Christoph Lameter
2005-04-28 22:05 ` Christoph Lameter
` (21 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: Christoph Lameter @ 2005-04-28 20:53 UTC (permalink / raw)
To: linux-ia64
On Thu, 28 Apr 2005, David Mosberger wrote:
> I'm unsure if it's a good idea to reduce the counter size.
We can still accomodate 2^24 = 16 million concurrent readers.
> Independent of that: using a name like "y" in a macro is bound to
> cause name collisions so it's a big no-no. Then why not declare
> "y" as a "volatile u8 *" so you can avoid the explicit smp_wmb()?
> This is ia64-specific code after all.
I thought that a memory barrier was needed to insure that the clearing of
the lock becomes visible after changes done in the critical section?
y is defined in its own block.
May be better do inline asm with an .nta store?
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
2005-04-28 20:43 ` David Mosberger
2005-04-28 20:53 ` Christoph Lameter
@ 2005-04-28 22:05 ` Christoph Lameter
2005-04-28 22:25 ` Zou, Nanhai
` (20 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: Christoph Lameter @ 2005-04-28 22:05 UTC (permalink / raw)
To: linux-ia64
This version uses an inline function and a nontemporal store to unlock
the rwlock.
write_lock uses a cmpxchg like the regular spin_lock but write_unlock uses
clear_bit which requires a load and then a loop over a cmpxchg. The
following patch makes write_unlock simply use a nontemporal store to clear
the highest 8 bits. We will then still have the lower 3 bytes (24 bits)
left to count the readers.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
Index: linux-2.6.11/include/asm-ia64/spinlock.h
=================================--- linux-2.6.11.orig/include/asm-ia64/spinlock.h 2005-03-01 23:37:48.000000000 -0800
+++ linux-2.6.11/include/asm-ia64/spinlock.h 2005-04-28 15:02:28.000000000 -0700
@@ -199,10 +199,10 @@ do { \
#define _raw_read_trylock(lock) generic_raw_read_trylock(lock)
-#define _raw_write_unlock(x) \
-({ \
- smp_mb__before_clear_bit(); /* need barrier before releasing lock... */ \
- clear_bit(31, (x)); \
-})
+static inline void _raw_write_unlock(spinlock_t *x) {
+ u8 *y = (u8 *)x;
+ barrier();
+ asm volatile ("st1.rel.nta [%0] = r0\n\t" :: "r"(y+3) : "memory" );
+}
#endif /* _ASM_IA64_SPINLOCK_H */
^ permalink raw reply [flat|nested] 25+ messages in thread* RE: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
` (2 preceding siblings ...)
2005-04-28 22:05 ` Christoph Lameter
@ 2005-04-28 22:25 ` Zou, Nanhai
2005-04-28 22:51 ` Christoph Lameter
` (19 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: Zou, Nanhai @ 2005-04-28 22:25 UTC (permalink / raw)
To: linux-ia64
> -----Original Message-----
> From: linux-ia64-owner@vger.kernel.org
> [mailto:linux-ia64-owner@vger.kernel.org] On Behalf Of Christoph
Lameter
> Sent: Friday, April 29, 2005 6:05 AM
> To: davidm@hpl.hp.com
> Cc: linux-ia64@vger.kernel.org
> Subject: Re: write_unlock: replace clear_bit with byte store
>
> This version uses an inline function and a nontemporal store to unlock
> the rwlock.
>
> write_lock uses a cmpxchg like the regular spin_lock but write_unlock
uses
> clear_bit which requires a load and then a loop over a cmpxchg. The
> following patch makes write_unlock simply use a nontemporal store to
clear
> the highest 8 bits. We will then still have the lower 3 bytes (24
bits)
> left to count the readers.
>
> Signed-off-by: Christoph Lameter <clameter@sgi.com>
>
> Index: linux-2.6.11/include/asm-ia64/spinlock.h
> =================================> --- linux-2.6.11.orig/include/asm-ia64/spinlock.h 2005-03-01
> 23:37:48.000000000 -0800
> +++ linux-2.6.11/include/asm-ia64/spinlock.h 2005-04-28
> 15:02:28.000000000 -0700
> @@ -199,10 +199,10 @@ do {
\
>
> #define _raw_read_trylock(lock) generic_raw_read_trylock(lock)
>
> -#define _raw_write_unlock(x)
\
> -({
\
> - smp_mb__before_clear_bit(); /* need barrier before releasing
lock... */
> \
> - clear_bit(31, (x));
\
> -})
> +static inline void _raw_write_unlock(spinlock_t *x) {
Shouldn't that an rwlock_t?
> + u8 *y = (u8 *)x;
> + barrier();
> + asm volatile ("st1.rel.nta [%0] = r0\n\t" :: "r"(y+3) : "memory"
);
> +}
>
> #endif /* _ASM_IA64_SPINLOCK_H */
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 25+ messages in thread* RE: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
` (3 preceding siblings ...)
2005-04-28 22:25 ` Zou, Nanhai
@ 2005-04-28 22:51 ` Christoph Lameter
2005-04-28 23:55 ` Chen, Kenneth W
` (18 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: Christoph Lameter @ 2005-04-28 22:51 UTC (permalink / raw)
To: linux-ia64
On Fri, 29 Apr 2005, Zou, Nanhai wrote:
> > +static inline void _raw_write_unlock(spinlock_t *x) {
>
> Shouldn't that an rwlock_t?
Correct. CC does not check types when doing inline functions? If I mispell
the type name then the compilation fails. I can put u64 * in there or
anything else and CC happily allows the passing of a rwlock_t *? Weird...
Maybe because of the type cast?
----------------------------------------------------------
write_lock uses a cmpxchg like the regular spin_lock but write_unlock uses
clear_bit which requires a load and then a loop over a cmpxchg. The
following patch makes write_unlock simply use a nontemporal store to clear
the highest 8 bits. We will then still have the lower 3 bytes (24 bits)
left to count the readers.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
Index: linux-2.6.11/include/asm-ia64/spinlock.h
=================================--- linux-2.6.11.orig/include/asm-ia64/spinlock.h 2005-03-01 23:37:48.000000000 -0800
+++ linux-2.6.11/include/asm-ia64/spinlock.h 2005-04-28 15:44:30.000000000 -0700
@@ -199,10 +199,10 @@ do { \
#define _raw_read_trylock(lock) generic_raw_read_trylock(lock)
-#define _raw_write_unlock(x) \
-({ \
- smp_mb__before_clear_bit(); /* need barrier before releasing lock... */ \
- clear_bit(31, (x)); \
-})
+static inline void _raw_write_unlock(rwlock_t *x) {
+ u8 *y = (u8 *)x;
+ barrier();
+ asm volatile ("st1.rel.nta [%0] = r0\n\t" :: "r"(y+3) : "memory" );
+}
#endif /* _ASM_IA64_SPINLOCK_H */
^ permalink raw reply [flat|nested] 25+ messages in thread* RE: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
` (4 preceding siblings ...)
2005-04-28 22:51 ` Christoph Lameter
@ 2005-04-28 23:55 ` Chen, Kenneth W
2005-04-29 0:21 ` Christoph Lameter
` (17 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: Chen, Kenneth W @ 2005-04-28 23:55 UTC (permalink / raw)
To: linux-ia64
Christoph Lameter wrote on Thursday, April 28, 2005 3:52 PM
> +static inline void _raw_write_unlock(rwlock_t *x) {
> + u8 *y = (u8 *)x;
> + barrier();
> + asm volatile ("st1.rel.nta [%0] = r0\n\t" :: "r"(y+3) : "memory" ); }
Perhaps you should make this code icc friendly by not using asm directly.
Intel compiler doesn't support asm statement.
^ permalink raw reply [flat|nested] 25+ messages in thread* RE: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
` (5 preceding siblings ...)
2005-04-28 23:55 ` Chen, Kenneth W
@ 2005-04-29 0:21 ` Christoph Lameter
2005-04-29 0:28 ` Chen, Kenneth W
` (16 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: Christoph Lameter @ 2005-04-29 0:21 UTC (permalink / raw)
To: linux-ia64
On Thu, 28 Apr 2005, Chen, Kenneth W wrote:
> Christoph Lameter wrote on Thursday, April 28, 2005 3:52 PM
> > +static inline void _raw_write_unlock(rwlock_t *x) {
> > + u8 *y = (u8 *)x;
> > + barrier();
> > + asm volatile ("st1.rel.nta [%0] = r0\n\t" :: "r"(y+3) : "memory" ); }
>
> Perhaps you should make this code icc friendly by not using asm directly.
> Intel compiler doesn't support asm statement.
How do I do a store with release and nontemporal semantics without asm?
^ permalink raw reply [flat|nested] 25+ messages in thread* RE: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
` (6 preceding siblings ...)
2005-04-29 0:21 ` Christoph Lameter
@ 2005-04-29 0:28 ` Chen, Kenneth W
2005-04-29 0:50 ` Christoph Lameter
` (15 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: Chen, Kenneth W @ 2005-04-29 0:28 UTC (permalink / raw)
To: linux-ia64
Christoph Lameter wrote on Thursday, April 28, 2005 5:22 PM
> How do I do a store with release and nontemporal semantics without asm?
Use ia64_st1_rel(), and add a wrapper in gcc_intrin.h. Though that only
takes care of store with release semantics.
^ permalink raw reply [flat|nested] 25+ messages in thread* RE: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
` (7 preceding siblings ...)
2005-04-29 0:28 ` Chen, Kenneth W
@ 2005-04-29 0:50 ` Christoph Lameter
2005-04-29 1:04 ` Chen, Kenneth W
` (14 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: Christoph Lameter @ 2005-04-29 0:50 UTC (permalink / raw)
To: linux-ia64
On Thu, 28 Apr 2005, Chen, Kenneth W wrote:
> Christoph Lameter wrote on Thursday, April 28, 2005 5:22 PM
> > How do I do a store with release and nontemporal semantics without asm?
>
> Use ia64_st1_rel(), and add a wrapper in gcc_intrin.h. Though that only
> takes care of store with release semantics.
Hmm... How about this one. Its still better than the cmpxchg for C and you
can do all the tricks you want with the C code later. I hope the bitfields
allocate the lowest bits first?
---
write_lock uses a cmpxchg like the regular spin_lock but write_unlock uses
clear_bit which requires a load and then a loop over a cmpxchg. The
following patch makes write_unlock simply use a nontemporal store to clear
the highest 8 bits. We will then still have the lower 3 bytes (24 bits)
left to count the readers.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
Index: linux-2.6.11/include/asm-ia64/spinlock.h
=================================--- linux-2.6.11.orig/include/asm-ia64/spinlock.h 2005-03-01 23:37:48.000000000 -0800
+++ linux-2.6.11/include/asm-ia64/spinlock.h 2005-04-28 17:48:11.000000000 -0700
@@ -117,8 +117,8 @@ do { \
#define spin_unlock_wait(x) do { barrier(); } while ((x)->lock)
typedef struct {
- volatile unsigned int read_counter : 31;
- volatile unsigned int write_lock : 1;
+ volatile unsigned int read_counter : 24;
+ volatile unsigned int write_lock : 8;
#ifdef CONFIG_PREEMPT
unsigned int break_lock;
#endif
@@ -174,6 +174,13 @@ do { \
(result = 0); \
})
+static inline void _raw_write_unlock(rwlock_t *x)
+{
+ u8 *y = (u8 *)x;
+ barrier();
+ asm volatile ("st1.rel.nta [%0] = r0\n\t" :: "r"(y+3) : "memory" );
+}
+
#else /* !ASM_SUPPORTED */
#define _raw_write_lock(l) \
@@ -195,14 +202,14 @@ do { \
(ia64_val = 0); \
})
+static inline void _raw_write_unlock(rwlock_t *x)
+{
+ barrier();
+ x->write_lock = 0;
+}
+
#endif /* !ASM_SUPPORTED */
#define _raw_read_trylock(lock) generic_raw_read_trylock(lock)
-#define _raw_write_unlock(x) \
-({ \
- smp_mb__before_clear_bit(); /* need barrier before releasing lock... */ \
- clear_bit(31, (x)); \
-})
-
#endif /* _ASM_IA64_SPINLOCK_H */
^ permalink raw reply [flat|nested] 25+ messages in thread* RE: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
` (8 preceding siblings ...)
2005-04-29 0:50 ` Christoph Lameter
@ 2005-04-29 1:04 ` Chen, Kenneth W
2005-04-29 1:48 ` Chen, Kenneth W
` (13 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: Chen, Kenneth W @ 2005-04-29 1:04 UTC (permalink / raw)
To: linux-ia64
Christoph Lameter wrote on Thursday, April 28, 2005 5:51 PM
> +static inline void _raw_write_unlock(rwlock_t *x) {
> + barrier();
> + x->write_lock = 0;
> +}
> +
> #endif /* !ASM_SUPPORTED */
This portion is broken, where is the release semantics for updating
the lock variable? Or where is the smp_mb() if you decide to use an
unordered store for the lock variable?
^ permalink raw reply [flat|nested] 25+ messages in thread* RE: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
` (9 preceding siblings ...)
2005-04-29 1:04 ` Chen, Kenneth W
@ 2005-04-29 1:48 ` Chen, Kenneth W
2005-04-29 7:09 ` David Mosberger
` (12 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: Chen, Kenneth W @ 2005-04-29 1:48 UTC (permalink / raw)
To: linux-ia64
Chen, Kenneth W wrote on Thursday, April 28, 2005 6:04 PM
> Christoph Lameter wrote on Thursday, April 28, 2005 5:51 PM
>
> > +static inline void _raw_write_unlock(rwlock_t *x) {
> > + barrier();
> > + x->write_lock = 0;
> > +}
> > +
> > #endif /* !ASM_SUPPORTED */
>
> This portion is broken, where is the release semantics for updating
> the lock variable? Or where is the smp_mb() if you decide to use an
> unordered store for the lock variable?
Oops, never mind. Missed the portion that write_lock is declared as
volatile. My bad. This code is OK.
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
` (10 preceding siblings ...)
2005-04-29 1:48 ` Chen, Kenneth W
@ 2005-04-29 7:09 ` David Mosberger
2005-04-29 11:37 ` David Mosberger
` (11 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: David Mosberger @ 2005-04-29 7:09 UTC (permalink / raw)
To: linux-ia64
>>>>> On Thu, 28 Apr 2005 15:05:16 -0700 (PDT), Christoph Lameter <clameter@engr.sgi.com> said:
Christoph> + u8 *y = (u8 *)x;
Same comments as before...
Christoph> + asm volatile ("st1.rel.nta [%0] = r0\n\t" :: "r"(y+3) : "memory" );
Let's not reintroduce in-line asm, please?
--david
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
` (11 preceding siblings ...)
2005-04-29 7:09 ` David Mosberger
@ 2005-04-29 11:37 ` David Mosberger
2005-04-29 15:19 ` Christoph Lameter
` (10 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: David Mosberger @ 2005-04-29 11:37 UTC (permalink / raw)
To: linux-ia64
>>>>> On Thu, 28 Apr 2005 13:53:11 -0700 (PDT), Christoph Lameter <clameter@engr.sgi.com> said:
Christoph> I thought that a memory barrier was needed to insure that
Christoph> the clearing of the lock becomes visible after changes
Christoph> done in the critical section?
With "volatile", the compiler will generate stX.rel...
Christoph> y is defined in its own block.
Ummh, macros 101: think about what happens for _raw_write_unlock(y)...
--david
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
` (12 preceding siblings ...)
2005-04-29 11:37 ` David Mosberger
@ 2005-04-29 15:19 ` Christoph Lameter
2005-04-29 15:20 ` Christoph Lameter
` (9 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: Christoph Lameter @ 2005-04-29 15:19 UTC (permalink / raw)
To: linux-ia64
On Fri, 29 Apr 2005, David Mosberger wrote:
> Let's not reintroduce in-line asm, please?
How do I do a nta store without inline asm? There is already lots of
inline asm in spinlock.h.
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
` (13 preceding siblings ...)
2005-04-29 15:19 ` Christoph Lameter
@ 2005-04-29 15:20 ` Christoph Lameter
2005-04-29 15:24 ` David Mosberger
` (8 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: Christoph Lameter @ 2005-04-29 15:20 UTC (permalink / raw)
To: linux-ia64
On Fri, 29 Apr 2005, David Mosberger wrote:
> Christoph> y is defined in its own block.
>
> Ummh, macros 101: think about what happens for _raw_write_unlock(y)...
Not if its defined in an inline function.
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
` (14 preceding siblings ...)
2005-04-29 15:20 ` Christoph Lameter
@ 2005-04-29 15:24 ` David Mosberger
2005-04-29 15:28 ` David Mosberger
` (7 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: David Mosberger @ 2005-04-29 15:24 UTC (permalink / raw)
To: linux-ia64
>>>>> On Fri, 29 Apr 2005 08:20:25 -0700 (PDT), Christoph Lameter <clameter@engr.sgi.com> said:
Christoph> On Fri, 29 Apr 2005, David Mosberger wrote:
Christoph> y is defined in its own block.
>> Ummh, macros 101: think about what happens for _raw_write_unlock(y)...
Christoph> Not if its defined in an inline function.
I thought it was declared inside a macro. Never mind.
--david
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
` (15 preceding siblings ...)
2005-04-29 15:24 ` David Mosberger
@ 2005-04-29 15:28 ` David Mosberger
2005-04-29 15:30 ` Christoph Lameter
` (6 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: David Mosberger @ 2005-04-29 15:28 UTC (permalink / raw)
To: linux-ia64
>>>>> On Fri, 29 Apr 2005 08:19:20 -0700 (PDT), Christoph Lameter <clameter@engr.sgi.com> said:
Christoph> On Fri, 29 Apr 2005, David Mosberger wrote:
>> Let's not reintroduce in-line asm, please?
Christoph> How do I do a nta store without inline asm?
You add a new intrinsic?
Christoph> There is already lots of inline asm in spinlock.h.
spinlock.h is special because it performs non-standard calls to the
out-of-line spinlock contention-handler, but those places are enclosed
inside ASM_SUPPORTED.
--david
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
` (16 preceding siblings ...)
2005-04-29 15:28 ` David Mosberger
@ 2005-04-29 15:30 ` Christoph Lameter
2005-04-29 15:38 ` David Mosberger
` (5 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: Christoph Lameter @ 2005-04-29 15:30 UTC (permalink / raw)
To: linux-ia64
On Fri, 29 Apr 2005, David Mosberger wrote:
> >>>>> On Fri, 29 Apr 2005 08:19:20 -0700 (PDT), Christoph Lameter <clameter@engr.sgi.com> said:
>
> Christoph> On Fri, 29 Apr 2005, David Mosberger wrote:
> >> Let's not reintroduce in-line asm, please?
>
> Christoph> How do I do a nta store without inline asm?
>
> You add a new intrinsic?
>
> Christoph> There is already lots of inline asm in spinlock.h.
>
> spinlock.h is special because it performs non-standard calls to the
> out-of-line spinlock contention-handler, but those places are enclosed
> inside ASM_SUPPORTED.
So is my version of inline asm int the latest version from yesterday.
There is an alternate version included for !ASM_SUPPORTED in C which does
not use an nta store.
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
` (17 preceding siblings ...)
2005-04-29 15:30 ` Christoph Lameter
@ 2005-04-29 15:38 ` David Mosberger
2005-04-29 15:46 ` Christoph Lameter
` (4 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: David Mosberger @ 2005-04-29 15:38 UTC (permalink / raw)
To: linux-ia64
>>>>> On Fri, 29 Apr 2005 08:30:27 -0700 (PDT), Christoph Lameter <clameter@engr.sgi.com> said:
Christoph> So is my version of inline asm int the latest version
Christoph> from yesterday. There is an alternate version included
Christoph> for !ASM_SUPPORTED in C which does not use an nta store.
Yes, but _if_ it's a good idea to use .nta with GCC, there is no
reason not to do the same with ICC. Don't introduce unnecessary
divergence.
--david
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
` (18 preceding siblings ...)
2005-04-29 15:38 ` David Mosberger
@ 2005-04-29 15:46 ` Christoph Lameter
2005-04-29 15:48 ` David Mosberger
` (3 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: Christoph Lameter @ 2005-04-29 15:46 UTC (permalink / raw)
To: linux-ia64
On Fri, 29 Apr 2005, David Mosberger wrote:
> >>>>> On Fri, 29 Apr 2005 08:30:27 -0700 (PDT), Christoph Lameter <clameter@engr.sgi.com> said:
>
> Christoph> So is my version of inline asm int the latest version
> Christoph> from yesterday. There is an alternate version included
> Christoph> for !ASM_SUPPORTED in C which does not use an nta store.
>
> Yes, but _if_ it's a good idea to use .nta with GCC, there is no
> reason not to do the same with ICC. Don't introduce unnecessary
> divergence.
The same situation of .nta only for GCC already exists for regular
spinlocks as a result of my nta unlock patch that I posted a week or so
ago.
I do not know too much about ICC...
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
` (19 preceding siblings ...)
2005-04-29 15:46 ` Christoph Lameter
@ 2005-04-29 15:48 ` David Mosberger
2005-04-29 15:51 ` Christoph Hellwig
` (2 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: David Mosberger @ 2005-04-29 15:48 UTC (permalink / raw)
To: linux-ia64
>>>>> On Fri, 29 Apr 2005 08:46:14 -0700 (PDT), Christoph Lameter <clameter@engr.sgi.com> said:
Christoph> On Fri, 29 Apr 2005, David Mosberger wrote:
>> >>>>> On Fri, 29 Apr 2005 08:30:27 -0700 (PDT), Christoph Lameter <clameter@engr.sgi.com> said:
Christoph> So is my version of inline asm int the latest version
Christoph> from yesterday. There is an alternate version included
Christoph> for !ASM_SUPPORTED in C which does not use an nta store.
>> Yes, but _if_ it's a good idea to use .nta with GCC, there is no
>> reason not to do the same with ICC. Don't introduce unnecessary
>> divergence.
Christoph> The same situation of .nta only for GCC already exists
Christoph> for regular spinlocks as a result of my nta unlock patch
Christoph> that I posted a week or so ago.
And that's an argument to make the situation worse? How about
cleaning up the previous patch instead?
--david
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
` (20 preceding siblings ...)
2005-04-29 15:48 ` David Mosberger
@ 2005-04-29 15:51 ` Christoph Hellwig
2005-04-29 15:55 ` Christoph Lameter
2005-04-29 16:01 ` David Mosberger
23 siblings, 0 replies; 25+ messages in thread
From: Christoph Hellwig @ 2005-04-29 15:51 UTC (permalink / raw)
To: linux-ia64
On Fri, Apr 29, 2005 at 08:48:43AM -0700, David Mosberger wrote:
> >> Yes, but _if_ it's a good idea to use .nta with GCC, there is no
> >> reason not to do the same with ICC. Don't introduce unnecessary
> >> divergence.
>
> Christoph> The same situation of .nta only for GCC already exists
> Christoph> for regular spinlocks as a result of my nta unlock patch
> Christoph> that I posted a week or so ago.
>
> And that's an argument to make the situation worse? How about
> cleaning up the previous patch instead?
I don't think it's fair to expect contributors to fix up ifdef'ed bits for
a propritary compiler. If HP and Intel care about it they can add the
features for icc later.
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
` (21 preceding siblings ...)
2005-04-29 15:51 ` Christoph Hellwig
@ 2005-04-29 15:55 ` Christoph Lameter
2005-04-29 16:01 ` David Mosberger
23 siblings, 0 replies; 25+ messages in thread
From: Christoph Lameter @ 2005-04-29 15:55 UTC (permalink / raw)
To: linux-ia64
On Fri, 29 Apr 2005, David Mosberger wrote:
> And that's an argument to make the situation worse? How about
> cleaning up the previous patch instead?
I was not aware of the situation with ICC. Sorry. Maybe I can get
to solving the ICC issue later this fall when I finally get a week or
so to get familiar with the compiler...
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: write_unlock: replace clear_bit with byte store
2005-04-28 20:32 write_unlock: replace clear_bit with byte store Christoph Lameter
` (22 preceding siblings ...)
2005-04-29 15:55 ` Christoph Lameter
@ 2005-04-29 16:01 ` David Mosberger
23 siblings, 0 replies; 25+ messages in thread
From: David Mosberger @ 2005-04-29 16:01 UTC (permalink / raw)
To: linux-ia64
>>>>> On Fri, 29 Apr 2005 16:51:53 +0100, Christoph Hellwig <hch@infradead.org> said:
Christoph> On Fri, Apr 29, 2005 at 08:48:43AM -0700, David Mosberger wrote:
>> >> Yes, but _if_ it's a good idea to use .nta with GCC, there is no
>> >> reason not to do the same with ICC. Don't introduce unnecessary
>> >> divergence.
Christoph> The same situation of .nta only for GCC already exists
Christoph> for regular spinlocks as a result of my nta unlock patch
Christoph> that I posted a week or so ago.
>> And that's an argument to make the situation worse? How about
>> cleaning up the previous patch instead?
Christoph> I don't think it's fair to expect contributors to fix up
Christoph> ifdef'ed bits for a propritary compiler. If HP and Intel
Christoph> care about it they can add the features for icc later.
I don't think this is about proprietary vs non-proprietary. It's
about whether the code is clean. I'd _love_ to get rid of inline asm
in the future when GCC supports intrinsics since that could lead to
significantly improved code.
(And no, I don't expect Chris to necessarily fix up the ICC bits, though
a reasonable best-effort wouldn't take much time.)
--david
^ permalink raw reply [flat|nested] 25+ messages in thread