Linux PARISC architecture development
 help / color / mirror / Atom feed
From: "Michael S. Zick" <mszick@morethan.org>
To: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
Cc: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] Does it lakes some cloberred r1 in
Date: Mon, 24 Apr 2006 13:00:13 -0500	[thread overview]
Message-ID: <200604241300.13265.mszick@morethan.org> (raw)
In-Reply-To: <200604241135.58306.mszick@morethan.org>

On Mon April 24 2006 11:35, you wrote:
> On Mon April 24 2006 10:35, you wrote:
> > > ldcw,co target_address
> > > 
> > > Where target_address includes the magic byte[0] of 
> > > the cache line.
> > 
> > Where is this documented?
> > 
> Well, they didn't put it in the instruction RTL where
> someone could find it.  It is a footnote or mentioned
> in passing somewhere.
> 
> I will look for it, I found it about 5 years ago when
> Matt and I discussed this on the list, I can find it again.
> 

Still looking...

> But it is reasonable - you don't want to waste the cache
> coherency bandwidth with every ldcw,co in the cache line.
> 
> > > Translation:
> > > 
> > > Spin on the ldcw,co not the ldw here.
> > 
> > I believe this makes sense as the errata specifies that the ldcw,co
> > operation has to be performed in cache on PA 2.0 machines:
> > http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,5310,00.html
> > 
> 

Right, notice that it was at the request of HP-UX group for non-I/O
devices.

Think of it this way:

ldcw, co Cache_Line[0]

The hardware, system wide, exclusive lock for this cache line.

A cache line is a big place...

ldcw, co Cache_Line[4 .. max-4]

This cpu now owns the cache line, so the other cpus do not need
to be updated, nor the cache coherency bandwidth burned up...
The non-zero cache line offset does this trick.

These are the per-cpu (cache line owner) semaphores (and/or data) for 
the multiple threads of execution that are servicing whatever caused
the cache line to be grabbed on a machine wide, exclusive lock.

But if our cpu is going to be a polite neighbor to the other cpus
in the machine, it will have to use an instruction (+completer)
that is immediately observable by the other cpus when it is done
with the hardware wide lock.

Yo - Software Engineering, are you home?

Mike
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

  reply	other threads:[~2006-04-24 18:00 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20060422154641.GC10514@quicksilver.road.mcmartin.ca>
2006-04-22 16:48 ` [parisc-linux] Does it lakes some cloberred r1 in John David Anglin
2006-04-23 16:18   ` Michael S. Zick
2006-04-23 17:06     ` Michael S. Zick
2006-04-24 15:35       ` John David Anglin
2006-04-24 16:25         ` Grant Grundler
2006-04-24 16:50           ` John David Anglin
2006-04-24 18:55             ` John David Anglin
2006-04-25  0:38             ` Grant Grundler
2006-04-26 16:42             ` Michael S. Zick
2006-04-24 16:35         ` Michael S. Zick
2006-04-24 18:00           ` Michael S. Zick [this message]
2006-04-24 19:15             ` John David Anglin
2006-04-24 21:57             ` Michael S. Zick
2006-04-24 22:40               ` John David Anglin
2006-04-24 18:46           ` John David Anglin
2006-04-24 19:12             ` Michael S. Zick
2006-04-24 21:07               ` John David Anglin
2006-04-25 15:17         ` Michael S. Zick
2006-04-25 18:52           ` Michael S. Zick
2006-04-25 21:42             ` John David Anglin
     [not found] <200604212013.k3LKDAbx003500@hiauly1.hia.nrc.ca>
2006-04-21 20:30 ` John David Anglin
2006-04-20 17:09 [parisc-linux] Does it lakes some cloberred r1 in __put_kernel_asm() 64bit? Carlos O'Donell
2006-04-20 17:28 ` [parisc-linux] Does it lakes some cloberred r1 in John David Anglin
2006-04-20 17:36   ` Michael S. Zick
2006-04-20 19:32     ` John David Anglin
2006-04-20 20:21       ` Michael S. Zick
2006-04-20 20:04   ` Carlos O'Donell
2006-04-20 21:29     ` John David Anglin
2006-04-21 18:52     ` Michael S. Zick

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200604241300.13265.mszick@morethan.org \
    --to=mszick@morethan.org \
    --cc=dave@hiauly1.hia.nrc.ca \
    --cc=parisc-linux@lists.parisc-linux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox