Messages in this thread | | | Date | Fri, 29 Oct 1999 09:07:15 +0200 | From | Ralf Baechle <> | Subject | Re: FD array expansion problem |
| |
On Thu, Oct 28, 1999 at 01:35:19PM +0200, Matthew Wilcox wrote:
> > BTW, does anyone know why fd array manipulations are performed via atomic > > operation (xchg) in some places (fd_install, expand_fdset)? > > It looks strange because > > 1) atomic operations don't cover all accesses; > > 2) these code parts are already protected by a write lock. > > I'd like to just plead with people _not_ to use xchg unnecessarily. > On PA-RISC, it is going to _suck_. PA-RISC's only atomic instruction > is load-and-zero. Therefore we have to have a spinlock in our generic > xchg implementation. And disable interrupts. Ugh. It's OK if you > xchg something with zero though, and most of the xchg's in the kernel > are with zero.
MIPS II instruction set and better and the Alpha don't have an xchg equivalent but ll / sc instructions, which are more universal. Using them to implement an xchg-like implementation however ends up as a a loop of at least five instructions which we'de prefarably want to avoid.
The MIPS I (R2000, R3000, embedded toys) situation is worse, they don't have atomic operations at all. Historical side note - external hardware was being used to implement atomic operations on such systems for SMP. I don't know the details but what I know looks bad enough that I probably will refuse to add R3000 SMP support. Performance is even worse, I've been told that atomic implementations were taking a number of microseconds in the range of three to four digits. Imagine, *miliseconds*.
Currently we have two types of atomic operations in the kernel, atomic with respect to interrupts including bottom half handlers and atomic with respect to other processors in a MP system. We however only have a single implementation of all atomic operations.
Ralf
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |