Commit Graph

17 Commits

Author SHA1 Message Date
Andrew Gallatin
7a966f2ded Remove extranious memory barriers, and correct the placement of a few others.
This provides a 30% reduction in system time and a 6% reduction in wallclock time
for a make buildworld on my xp1000 (one 21264).

FWIW, I've been running this for nearly 2 months without problems.

Portions submitted by: ticso, jhb
Tested by: jhb (ds20 dual 21264)
2002-10-30 01:41:44 +00:00
John Baldwin
4c86c028ac Use the newer "+" modifier on output contraints when a register or
memory datum is used for both input and output instead of using
matching constraints.
2002-10-25 20:22:12 +00:00
Mark Murray
0a7d7bdc02 Wrap GNUish asm() code in #ifdef __GNUC__ 2002-09-21 19:12:59 +00:00
John Baldwin
ae3f633bae - Apparently, the Alpha ABI mandates that arguments be passed sign-extended
regardless of if they are signed or unsigned since it is easier to work
  with sign-extended values.  Thus, remove the disabled zapnot to
  zero-extend the sign-extended value we read from *p in atomic_cmpset_32()
  since the cmpval we are comparing against should already be
  sign-extended.
- To ensure that the compiler knows to sign-extend the upper 32 bits of
  cmpval rather than leaving garbage in there, cast the appropriately in
  the constraints section.

Help from:	Richard Henderson <rth@redhat.com>
2002-05-17 05:45:39 +00:00
John Baldwin
8f0dda1601 Temporarily disable Jeff's fix for atomic_cmpset_32() to zero-extend the
value we load from memory.  gcc3.1 passes in the u_int32_t old value to
compare against as a _sign_-extended 64-bit value for some reason (bug?).
This is a temporary workaround so kernels work again on alpha.
2002-05-11 04:27:39 +00:00
Jeff Roberson
c4b689f10a zapnot the signed bits in atomic_cmpset_32. Previously this did not work with
negative values because the original value was sign extended but the compared
value was not.
2002-05-08 05:19:56 +00:00
John Baldwin
49f886f5d3 Be conservative and always perform an mb after an atomic_cmpset operation. 2001-06-22 21:13:20 +00:00
John Baldwin
2bec909c3d - Fix memory barriers in atomic operations so that the barriers are always
"inside" of locked regions.  That is, an acquire atomic operation will
  always enforce a memory barrier after the atomic operation and a release
  operation will always enforce a memory barrier before the atomic
  operation.
- Explicitly use 'mb' instead of 'wmb' in release atomic operations.  The
  'wmb' memory barrier is not strong enough to guarantee coherence with
  other processors.  This is effectively a nop since alpha_wmb() actually
  performs a 'mb' and not a 'wmb', but I wanted the code to be more
  correct since at some point in the future alpha_wmb()'s implementation
  may switch to being a real 'wmb'.
2001-04-17 02:50:05 +00:00
John Baldwin
2a1c4d6378 Only use 1 set of memory barrier operations with the atomic_*_{acq,rel}_ptr
functions.
2000-10-25 00:15:21 +00:00
John Baldwin
bb352e20a2 Grrrr. Fix the order of the #define's so atomic_cmpset_{acq,rel}_long
are defined before atomic_cmpset_{acq,rel}_ptr tries to call them.
2000-10-20 19:53:52 +00:00
John Baldwin
6d02703c2f Fix the atomic_cmpset_{acq,rel}_ptr() functions to do proper type-casting. 2000-10-20 19:46:02 +00:00
John Baldwin
ccbdd9ee59 - Expand the set of atomic operations to optionally include memory barriers
in most of the atomic operations.  Now for these operations, you can
  use the normal atomic operation, you can use the operation with a read
  barrier, or you can use the operation with a write barrier.  The function
  names follow the same semantics used in the ia64 instruction set.  An
  atomic operation with a read barrier has the extra suffix 'acq', due to
  it having "acquire" semantics.  An atomic operation with a write barrier
  has the extra suffix 'rel'.  These suffixes are inserted between the
  name of the operation to perform and the typename.  For example, the
  atomic_add_int() function now has 3 variants:
  - atomic_add_int() - this is the same as the previous function
  - atomic_add_acq_int() - this function combines the add operation with a
    read memory barrier
  - atomic_add_rel_int() - this function combines the add operation with a
    write memory barrier
- Add 'ptr' to the list of types that we can perform atomic operations
  on.  This allows one to do atomic operations on uintptr_t's.  This is
  useful in the mutex code, for example, because the actual mutex lock is
  a pointer.
- Add two new operations for doing loads and stores with memory barriers.
  The new load operations use a read barrier before the load, and the
  new store operations use a write barrier after the load.  For example,
  atomic_load_acq_int() will atomically load an integer as well as
  enforcing a read barrier.
2000-10-20 07:00:48 +00:00
John Baldwin
b4645202b5 Add atomic_readandclear_int and atomic_readandclear_long. 2000-10-05 22:19:50 +00:00
Doug Rabson
7a0758ab68 * Redo the cmpset inlines to use one less register. This incidentally
fixes a serious problem with the previous version where an input could
  have been placed in the same register as an output which would stop
  the inline from working properly.

* Redo atomic_{set,clear,add,subtract}_{32,64} as inlines since the code
  sequence is shorter than the call sequence to the code in atomic.s.
  I will remove the functions from atomic.s after a grace period to allow
  people to rebuild kernel modules.
2000-09-12 22:45:44 +00:00
Poul-Henning Kamp
819e370c3b Introduce atomic_cmpset_int() and atomic_cmpset_long() from SMPng a
few hours earlier than the rest.

The next DEVFS commit needs these functions.

Alpha versions by: dfr
i386 versions by: jakeb

Approved by:    SMPng
2000-09-06 11:21:14 +00:00
Peter Wemm
c3aac50f28 $Id$ -> $FreeBSD$ 1999-08-28 01:08:13 +00:00
Doug Rabson
069e9bc1b4 Change various syscalls to use size_t arguments instead of u_int.
Add some overflow checks to read/write (from bde).

Change all modifications to vm_page::flags, vm_page::busy, vm_object::flags
and vm_object::paging_in_progress to use operations which are not
interruptable.

Reviewed by: Bruce Evans <bde@zeta.org.au>
1998-08-24 08:39:39 +00:00