On Thu, Jun 18, 2009 at 20:47, Paul Mackerras wrote:
> Mike Frysinger writes:
>> On Sat, Jun 13, 2009 at 03:10, Paul Mackerras wrote:
>> > +typedef struct {
>> > + long long counter;
>> > +} atomic64_t;
>>
>> lack of volatile seems odd compared to:
>> include/linux/types.h:
>> typedef struct
Mike Frysinger writes:
> On Sat, Jun 13, 2009 at 03:10, Paul Mackerras wrote:
> > +typedef struct {
> > + long long counter;
> > +} atomic64_t;
>
> lack of volatile seems odd compared to:
> include/linux/types.h:
> typedef struct {
> volatile int counter;
> } atomic_t;
> -mike
It's onl
On Thu, 2009-06-18 at 19:55 -0400, Mike Frysinger wrote:
> On Sat, Jun 13, 2009 at 03:10, Paul Mackerras wrote:
> > +typedef struct {
> > + long long counter;
> > +} atomic64_t;
>
> lack of volatile seems odd compared to:
> include/linux/types.h:
> typedef struct {
> volatile int counter
On Sat, Jun 13, 2009 at 03:10, Paul Mackerras wrote:
> +typedef struct {
> + long long counter;
> +} atomic64_t;
lack of volatile seems odd compared to:
include/linux/types.h:
typedef struct {
volatile int counter;
} atomic_t;
-mike
___
Linuxpp
On Sun, Jun 14, 2009 at 04:04:36PM +0300, Avi Kivity wrote:
> Paul Mackerras wrote:
>> Avi Kivity writes:
>>
>>
>>> An alternative implementation using 64-bit cmpxchg will recover most
>>> of the costs of hashed spinlocks. I assume most serious 32-bit
>>> architectures have them?
>>>
>>
Roland Dreier writes:
> FWIW, Nehalem EX actually goes to 8 cores/16 threads per socket. But
> worrying about 32-bit performance on Nehalem is a little silly -- this
> simplest solution is simply to run a 64-bit kernel.
I'm not worried about ANY x86 processor, 32-bit or 64-bit, in fact,
since x8
> The new Nehalems provide 8 logical threads in a single socket. All
> those threads share a cache, and they have cmpxchg8b anyway, so this
> won't matter.
FWIW, Nehalem EX actually goes to 8 cores/16 threads per socket. But
worrying about 32-bit performance on Nehalem is a little silly -- t
Paul Mackerras wrote:
Avi Kivity writes:
An alternative implementation using 64-bit cmpxchg will recover most of
the costs of hashed spinlocks. I assume most serious 32-bit
architectures have them?
Have a 64-bit cmpxchg, you mean? x86 is the only one I know of, and
it already has a
Avi Kivity writes:
> An alternative implementation using 64-bit cmpxchg will recover most of
> the costs of hashed spinlocks. I assume most serious 32-bit
> architectures have them?
Have a 64-bit cmpxchg, you mean? x86 is the only one I know of, and
it already has an atomic64_t implementation
Linus Torvalds wrote:
On Sat, 13 Jun 2009, Linus Torvalds wrote:
On Sat, 13 Jun 2009, Paul Mackerras wrote:
Linus, Andrew: OK if this goes in via the powerpc tree?
Ok by me.
Btw, do 32-bit architectures really necessarily want 64-bit performance
counters?
I realize tha
On Saturday 13 June 2009, Paul Mackerras wrote:
> +extern long long atomic64_read(const atomic64_t *v);
> +extern void atomic64_set(atomic64_t *v, long long i);
> +extern void atomic64_add(long long a, atomic64_t *v);
> +extern long long atomic64_add_return(long long a, atomic64_t *v);
> +e
* Linus Torvalds wrote:
> On Sat, 13 Jun 2009, Linus Torvalds wrote:
> >
> > On Sat, 13 Jun 2009, Paul Mackerras wrote:
> > >
> > > Linus, Andrew: OK if this goes in via the powerpc tree?
> >
> > Ok by me.
>
> Btw, do 32-bit architectures really necessarily want 64-bit
> performance counters
On Sat, 13 Jun 2009, Linus Torvalds wrote:
>
> On Sat, 13 Jun 2009, Paul Mackerras wrote:
> >
> > Linus, Andrew: OK if this goes in via the powerpc tree?
>
> Ok by me.
Btw, do 32-bit architectures really necessarily want 64-bit performance
counters?
I realize that 32-bit counters will overf
On Sat, 13 Jun 2009, Paul Mackerras wrote:
>
> Linus, Andrew: OK if this goes in via the powerpc tree?
Ok by me.
Linus
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Many processor architectures have no 64-bit atomic instructions, but
we need atomic64_t in order to support the perf_counter subsystem.
This adds an implementation of 64-bit atomic operations using hashed
spinlocks to provide atomicity. For each atomic operation, the address
of the atomic64_t var
15 matches
Mail list logo
