linux-mips
[Top] [All Lists]

Re: Build failure for R3000 DECstation

To: Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
Subject: Re: Build failure for R3000 DECstation
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Wed, 15 Nov 2000 21:17:35 +0100 (MET)
Cc: Jun Sun <jsun@mvista.com>, linux-mips@oss.sgi.com, Ralf Baechle <ralf@oss.sgi.com>
In-reply-to: <XFMail.001115204613.Harald.Koerfgen@home.ivm.de>
Organization: Technical University of Gdansk
Reply-to: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Sender: owner-linux-mips@oss.sgi.com
On Wed, 15 Nov 2000, Harald Koerfgen wrote:

> On 15-Nov-00 Jun Sun wrote:
> [R3000 UP userland spinlocks]
> > In fact, I don't think you can perform automic operation ONLY based on
> > the knowledge whether a context switch has happened during a specified
> > period.  (It should be interesting to see if we can actually "prove"
> > it.)
> 
> I doubt this as well, although I'd love to be proven wrong.

 Well, on UP the only events that can break atomicity are exceptions (here
I treat interrupts as exceptions as well) and DMA accesses.  I don't think
we do DMA to user space, so this should not be a problem.  So if we can
detect an exception occured we may assume an operation failed and retry. 
It's not a problem for an exception handler to clobber k0 or k1 upon exit. 

 Unfortunately we cannot use this implementation in the userland or we
risk problems when running on SMP systems -- an ISA-I user binary might
very well be run on an ISA-II (or higher) SMP system.  But we can use it
in the kernel, for sysmips() and everything else.  All we have to be
careful about is not to allow DMA accesses to spinlocks.  I don't think
this is a problem in reality. 

  Maciej

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


<Prev in Thread] Current Thread [Next in Thread>