MIPS_ATOMIC_SET in sys_sysmips()

MIPS_ATOMIC_SET in sys_sysmips()

[Jun Sun]

It looks like sometime after test5 the MIPS_ATOMIC_SET case in sys_sysmips()
function in the CVS tree is changed.  The new code now uses ll/sc instructions
and handles syscall trace, etc.. 

This change does not make sense to me.  The userland typically uses
MIPS_ATOMIC_SET when ll/sc instructions are not available.  But the new code
itself uses ll/sc, which pretty much forfeit the purpose.  Or do I miss
something else?

What do we offer to machines without ll/sc?

BTW, what is the wrong with previous code?  I understand it may be broken in
SMP case, but I think that is fixable.  Comments?


Jun

Re: MIPS_ATOMIC_SET in sys_sysmips()

[Maciej W. Rozycki]

On Mon, 18 Dec 2000, Jun Sun wrote:

> It looks like sometime after test5 the MIPS_ATOMIC_SET case in sys_sysmips()
> function in the CVS tree is changed.  The new code now uses ll/sc instructions
> and handles syscall trace, etc.. 
> 
> This change does not make sense to me.  The userland typically uses
> MIPS_ATOMIC_SET when ll/sc instructions are not available.  But the new code
> itself uses ll/sc, which pretty much forfeit the purpose.  Or do I miss
> something else?

 There is no problem with using ll/sc in sysmips() itself for machines
that support them. 

> What do we offer to machines without ll/sc?

 I asked Ralf for a clarification of the sysmips(MIPS_ATOMIC_SET, ...) 
call before I write better code.  No response so far.  I'm now really
cosidering implementing the Ultrix atomic_op() syscall -- at least it has
a well-known defined behaviour. 

> BTW, what is the wrong with previous code?  I understand it may be broken in
> SMP case, but I think that is fixable.  Comments?

 The previous code was definitely broken -- depending on the path taken it
would return either the value fetched from memory or an error code.  No
way to distinguish between them. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: MIPS_ATOMIC_SET in sys_sysmips()

[Harald Koerfgen]

On 19-Dec-00 Maciej W. Rozycki wrote:
> On Mon, 18 Dec 2000, Jun Sun wrote:
>> What do we offer to machines without ll/sc?
> 
>  I asked Ralf for a clarification of the sysmips(MIPS_ATOMIC_SET, ...) 
> call before I write better code.  No response so far.  I'm now really
> cosidering implementing the Ultrix atomic_op() syscall -- at least it has
> a well-known defined behaviour. 

Another possibility would be to rely on the userland ll/sc emulation in the
kernel. The one in the linux-vr tree seems to be working well and can easily be
backported to Linux/MIPS.

Advantage: userland binary compatibility.
Disadvantage: possibility for a lot of context switches for userland atomic
operations.
 
Having a sysmips(MIPS_ATOMIC_SET, ...) or atomic_op() solution would probably a
lot faster.

Maybe we should implement both :)

-- 
Regards,
Harald

Re: MIPS_ATOMIC_SET in sys_sysmips()

[Maciej W. Rozycki]

On Tue, 19 Dec 2000, Harald Koerfgen wrote:

> Another possibility would be to rely on the userland ll/sc emulation in the
> kernel. The one in the linux-vr tree seems to be working well and can easily be
> backported to Linux/MIPS.

 This should work but it looks ugly to me and the performance would suck
horribly. 

> Advantage: userland binary compatibility.
> Disadvantage: possibility for a lot of context switches for userland atomic
> operations.

 We may implement the emulation anyway, just like we emulate unaligned
accesses. 

> Having a sysmips(MIPS_ATOMIC_SET, ...) or atomic_op() solution would probably a
> lot faster.
> 
> Maybe we should implement both :)

 If we could afford another syscall number then I would prefer atomic_op() 
at the moment as it is well-documented and it does not overload one
function for various purposes, i.e. it's a bit faster. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: MIPS_ATOMIC_SET in sys_sysmips()

[Jun Sun]

"Maciej W. Rozycki" wrote:
> 
> On Mon, 18 Dec 2000, Jun Sun wrote:
> 
> > It looks like sometime after test5 the MIPS_ATOMIC_SET case in sys_sysmips()
> > function in the CVS tree is changed.  The new code now uses ll/sc instructions
> > and handles syscall trace, etc..
> >
> > This change does not make sense to me.  The userland typically uses
> > MIPS_ATOMIC_SET when ll/sc instructions are not available.  But the new code
> > itself uses ll/sc, which pretty much forfeit the purpose.  Or do I miss
> > something else?
> 
>  There is no problem with using ll/sc in sysmips() itself for machines
> that support them.
> 

Sure - but with ll/sc available the user programs don't need to issue
sysmip(MIPS_ATOMIC_SET,...) at the first place ...

> > What do we offer to machines without ll/sc?
> 
>  I asked Ralf for a clarification of the sysmips(MIPS_ATOMIC_SET, ...)
> call before I write better code.  No response so far.  I'm now really
> cosidering implementing the Ultrix atomic_op() syscall -- at least it has
> a well-known defined behaviour.
>

Where can I find the definitino of atomic_op()?  Or can you tell us a little
more about it? 

> > BTW, what is the wrong with previous code?  I understand it may be broken in
> > SMP case, but I think that is fixable.  Comments?
> 
>  The previous code was definitely broken -- depending on the path taken it
> would return either the value fetched from memory or an error code.  No
> way to distinguish between them.
>

I notice that.  I notice glibc is the only "customer" of the MIPS_SET_ATOMIC
call, the bug does not appear to be a big deal because error should not
happen.  Of course, it will be nice to fix it.

Jun

Re: MIPS_ATOMIC_SET in sys_sysmips()

[Maciej W. Rozycki]

On Tue, 19 Dec 2000, Jun Sun wrote:

> >  There is no problem with using ll/sc in sysmips() itself for machines
> > that support them.
> 
> Sure - but with ll/sc available the user programs don't need to issue
> sysmip(MIPS_ATOMIC_SET,...) at the first place ...

 You may be running a MIPS I binary on a MIPS II+ SMP system and the
binary has to run absolutely correctly.  Programs affected include ones
that use threads or that use locks in shared memory.

> >  I asked Ralf for a clarification of the sysmips(MIPS_ATOMIC_SET, ...)
> > call before I write better code.  No response so far.  I'm now really
> > cosidering implementing the Ultrix atomic_op() syscall -- at least it has
> > a well-known defined behaviour.
> 
> Where can I find the definitino of atomic_op()?  Or can you tell us a little
> more about it? 

 You may search the Net for atomic_op -- you should find a couple of
Ultrix man pages.  A copy is included below for your convenience.

> >  The previous code was definitely broken -- depending on the path taken it
> > would return either the value fetched from memory or an error code.  No
> > way to distinguish between them.
> 
> I notice that.  I notice glibc is the only "customer" of the MIPS_SET_ATOMIC
> call, the bug does not appear to be a big deal because error should not
> happen.  Of course, it will be nice to fix it.

 It is at the moment, but I can see other users once we establish the API. 
PostgreSQL is one of them.  It would call _test_and_set() but it implies
the latter should work as expected.  The _test_and_set() function is
documented in the MIPS ABI supplement and the underlying syscall
(whichever it is) must provide means for the fuction to behave as
expected.  Besides, if we want this to be a compatibility call, then we
should at least make it behave in a compatible way.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

                                                                 atomic_op(2)

   Name
     atomic_op - perform test and set operation.

   Syntax
     #include <sys/lock.h>

     int atomic_op(op, addr)
     int op;
     int *addr;

   Arguments

     op             This argument is the operation type.  If the operation
                    type is ATOMIC_SET, this call specifies the test and set
                    operation on location addr.  If the operation type is
                    ATOMIC_CLEAR, this call specifies the clear operation on
                    location addr.

     addr           This is the target address of the operation.

   Description
     The atomic_op call provides test and set operation at a user address.

     For RISC systems, atomic_op is executed as a system call.  For VAX sys-
     tems, a system call is not executed for this library function.

   Return Values
     If the atomic_op operation succeeds, then 0 is returned.  Otherwise a -1
     is returned, and a more specific error code is stored in errno.

   Diagnostics

     [EBUSY]        The location specified by addr is already set.

     [EINVAL]       The op is not a valid operation type.

     [EACCES]       The address specified in addr is not write accessible.

     [EALIGN]       The addr is not on an integer boundary.