[parisc-linux] Anyone got a few moments?

[parisc-linux] Anyone got a few moments?

[Matthew Wilcox]

Which of the people involved in this project know PA-RISC assembler?

We need xchg() written (in include/asm-parisc/system.h) before the
networking will compile.  We're going to need other stuff written too of
course; I know ARM assembler, so I guess I could probably learn PA-RISC
asm if no-one else wants to.

-- 
Matthew Wilcox <willy@bofh.ai>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson

Re: [parisc-linux] Anyone got a few moments?

[Grant Grundler]

Matthew Wilcox wrote:
> 
> Which of the people involved in this project know PA-RISC assembler?
> 
> We need xchg() written (in include/asm-parisc/system.h) before the
> networking will compile.  We're going to need other stuff written too of
> course; I know ARM assembler, so I guess I could probably learn PA-RISC
> asm if no-one else wants to.

What does xchg() do?

If it's a byte swapper, look at "PA-RISC 2.0 Architecture", by Gerry Kane
from HP Professionl books, page I-6. That's "Programming Notes" section.
Gives examples for "Endian byte swapping" for 32 and 64-bit quantities.
They work - HP-UX is using them.

grant


Grant Grundler
Enterprise Systems Technology Lab
+1.408.447.7253

Re: [parisc-linux] Anyone got a few moments?

[Matthew Wilcox]

On Mon, Jun 28, 1999 at 10:09:16AM -0700, Grant Grundler wrote:
> Matthew Wilcox wrote:
> > 
> > Which of the people involved in this project know PA-RISC assembler?
> > 
> > We need xchg() written (in include/asm-parisc/system.h) before the
> > networking will compile.  We're going to need other stuff written too of
> > course; I know ARM assembler, so I guess I could probably learn PA-RISC
> > asm if no-one else wants to.
> 
> What does xchg() do?

/*
 * Atomic [test&set] exchange
 *
 *      void *xchg_u32(void *ptr, unsigned long val)
 * Changes the memory location '*ptr' to be val and returns
 * the previous value stored there.
 */

It's atomic with respect to interrupts and other CPUs.

PA-RISC 2.0 seems to have LDC{W,D}, but that's going to make implementation
a real pain.

> If it's a byte swapper, look at "PA-RISC 2.0 Architecture", by Gerry Kane
> from HP Professionl books, page I-6. That's "Programming Notes" section.
> Gives examples for "Endian byte swapping" for 32 and 64-bit quantities.
> They work - HP-UX is using them.

thanks for the tip.  No-one's written those yet; I'll do those next.

-- 
Matthew Wilcox <willy@bofh.ai>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson

Re: [parisc-linux] Anyone got a few moments?

[Jeffrey A Law]

  In message <19990628193404.I30362@mencheca.ch.genedata.com>you write:
  > > What does xchg() do?
  > 
  > /*
  >  * Atomic [test&set] exchange
  >  *
  >  *      void *xchg_u32(void *ptr, unsigned long val)
  >  * Changes the memory location '*ptr' to be val and returns
  >  * the previous value stored there.
  >  */
  > 
tsk tsk, that is a highly non-portable API for atomic operations.

  > It's atomic with respect to interrupts and other CPUs.
  > 
  > PA-RISC 2.0 seems to have LDC{W,D}, but that's going to make implementation
  > a real pain.
Yes.  Major pain since the only useful atomic operations are load & clear
word/double as you noted.

Why does linux want an "exchange"-like API for atomic operations?  That
just seems totally weird and stupid.


jeff

Re: [parisc-linux] Anyone got a few moments?

[Matthew Wilcox]

On Mon, Jun 28, 1999 at 11:47:56AM -0600, Jeffrey A Law wrote:
> Yes.  Major pain since the only useful atomic operations are load & clear
> word/double as you noted.

That does seem to be the majority of uses (based on a grep).  But not all
are, unfortunately:

./drivers/net/slip.c:   rbuff = xchg(&sl->rbuff, rbuff);
./drivers/net/slip.c:   xbuff = xchg(&sl->xbuff, xbuff);
./drivers/net/slip.c:   cbuff = xchg(&sl->cbuff, cbuff);
./drivers/net/slip.c:   slcomp = xchg(&sl->slcomp, slcomp);
./drivers/net/slip.c:   xbuff    = xchg(&sl->xbuff, xbuff);
./drivers/net/slip.c:   rbuff    = xchg(&sl->rbuff, rbuff);
./drivers/net/slip.c:   cbuff    = xchg(&sl->cbuff, cbuff);
./drivers/scsi/scsi_queue.c:    cpnt = xchg(&host->pending_commands, cmd);
./drivers/scsi/scsi_queue.c:    cmd = xchg(&host->pending_commands, cpnt);
./fs/smbfs/sock.c:      data_ready = xchg(&sk->data_ready, smb_data_callback);
./fs/smbfs/sock.c:      data_ready = xchg(&sk->data_ready, server->data_ready);
./kernel/sys.c: mask = xchg(&current->fs->umask, mask & S_IRWXUGO);
./mm/slab.c:    if (xchg((unsigned long *)objp, SLAB_RED_MAGIC2) != SLAB_RED_MAG
IC1)
./mm/slab.c:    if (xchg((unsigned long *)(objp+cachep->c_org_size), SLAB_RED_MA
GIC2) != SLAB_RED_MAGIC1)
./mm/slab.c:    if (xchg((unsigned long *)objp, SLAB_RED_MAGIC1) != SLAB_RED_MAG
IC2) {
./mm/slab.c:    if (xchg((unsigned long *)(objp+cachep->c_org_size+BYTES_PER_WOR
D), SLAB_RED_MAGIC1) != SLAB_RED_MAGIC2) {
./net/core/utils.c:     toks += now - xchg(&last_msg, now);
./net/ipv4/ip_forward.c:                        dst_release(xchg(&skb->dev->fast
path[h], dst_clone(&rt->u.dst)));
./net/ipv4/ip_sockglue.c:                       opt = xchg(&sk->opt, opt);
./net/ipv4/tcp_ipv4.c:  dst_release(xchg(&sk->dst_cache, rt));
./net/ipv4/tcp_ipv4.c:          dst_release(xchg(&sk->dst_cache, &rt->u.dst));
./net/ipv6/ipv6_sockglue.c:             opt = xchg(&np->opt, opt);
./net/ipv6/tcp_ipv6.c:                          skb = xchg(&sk->net_pinfo.af_ine
t6.pktoptions, skb2);
./net/sched/cls_rsvp.h:                 tcf_police_release(xchg(&f->police, poli
ce));
./net/sched/cls_u32.c:          ht_down = xchg(&n->ht_down, ht_down);
./net/sched/cls_u32.c:          tcf_police_release(xchg(&n->police, police));
./net/sched/sch_cbq.c:          if ((*old = xchg(&cl->q, new)) != NULL)
./net/sched/sch_cbq.c:                  rtab = xchg(&cl->R_tab, rtab);
./net/sched/sch_generic.c:      qdisc = xchg(&dev->qdisc, &noop_qdisc);
./net/sched/sch_prio.c: *old = xchg(&q->queues[band], new);
./net/sched/sch_teql.c:         teql_neigh_release(xchg(&q->ncache, n));


and that's it.  That's only 31 uses where xchg couldn't be replaced
with get_and_zero.  I suspect most of these are using this mechanism to
walk a list without using a spinlock.  The slab uses are debug code only
(so they aren't performance critical by any means).  I bet most of these
uses could be removed without _too_ many problems.  I wonder what Linus'
opinion is on this.

-- 
Matthew Wilcox <willy@bofh.ai>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson

Re: [parisc-linux] Anyone got a few moments?

[Alan Cox]

> > Yes.  Major pain since the only useful atomic operations are load & clear
> > word/double as you noted.
> 
> and that's it.  That's only 31 uses where xchg couldn't be replaced
> with get_and_zero.  I suspect most of these are using this mechanism to
> walk a list without using a spinlock.  The slab uses are debug code only
> (so they aren't performance critical by any means).  I bet most of these
> uses could be removed without _too_ many problems.  I wonder what Linus'
> opinion is on this.

The sparc only has swap byte with 0xFF. They also have to use a small spinlock
for doing 32/64bit xchg ops. Thats ok. Xchg is only hopefully fast - since
on most machines xchg is a bus locker or pushes to ram the difference will
be minimal. 

The Alpha/Mips probably have it the nicest with the load locked/conditional
store.

Re: [parisc-linux] Anyone got a few moments?

[Matthew Wilcox]

On Mon, Jun 28, 1999 at 07:37:05PM +0100, Alan Cox wrote:
> > > Yes.  Major pain since the only useful atomic operations are load & clear
> > > word/double as you noted.
> > 
> > and that's it.  That's only 31 uses where xchg couldn't be replaced
> > with get_and_zero.  I suspect most of these are using this mechanism to
> > walk a list without using a spinlock.  The slab uses are debug code only
> > (so they aren't performance critical by any means).  I bet most of these
> > uses could be removed without _too_ many problems.  I wonder what Linus'
> > opinion is on this.
> 
> The sparc only has swap byte with 0xFF. They also have to use a small spinlock
> for doing 32/64bit xchg ops. Thats ok. Xchg is only hopefully fast - since
> on most machines xchg is a bus locker or pushes to ram the difference will
> be minimal. 

Okay.  Do you think we stand a chance of pushing a new call past linux
-- get_and_zero(*ptr), as this will make most of the calls efficient
on PA-RISC?  Or would a better idea be to check if the argument to be
swapped is zero; if it is use the special instructions; if not fall back
to a spinlock?

-- 
Matthew Wilcox <willy@bofh.ai>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson

Re: [parisc-linux] Anyone got a few moments?

[Alan Cox]

> Okay.  Do you think we stand a chance of pushing a new call past linux
> -- get_and_zero(*ptr), as this will make most of the calls efficient
> on PA-RISC?  Or would a better idea be to check if the argument to be
> swapped is zero; if it is use the special instructions; if not fall back
> to a spinlock?

For now I'd get it working with xchg() - the zero check isnt worth it. Get
it going the stupid way then worry

Re: [parisc-linux] Anyone got a few moments?

[Alan Cox]

> Yes.  Major pain since the only useful atomic operations are load & clear
> word/double as you noted.
> 
> Why does linux want an "exchange"-like API for atomic operations?  That
> just seems totally weird and stupid.

Its very very efficient if you have an exchange operation or you have
ll/sc. Most platforms Linux runs on have these.

Alan