public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Robin Holt <holt@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [RFC 0/4] Add SN2 Special Memory driver.
Date: Thu, 09 Sep 2004 17:59:37 +0000	[thread overview]
Message-ID: <20040909175937.GC23863@lnx-holt.americas.sgi.com> (raw)
In-Reply-To: <20040909163638.GA23178@lnx-holt.americas.sgi.com>

On Thu, Sep 09, 2004 at 06:21:56PM +0100, Christoph Hellwig wrote:
> On Thu, Sep 09, 2004 at 11:36:38AM -0500, Robin Holt wrote:
> > 
> > This driver provides three different devices for mmap'ing pages which
> > are not visible to the kernel.
> > 
> > sgi_fetchops) atomic operations performed by the SN2 memory controller.
> > 	These operations are performed using uncached memory
> > 	references with an offset of the address specifying the
> > 	operation (add, sub) to perform.
> > 
> > sgi_uncached) Provides a device which supports mapping pages which
> > 	will only be referenced uncached.  These use the Intel ia64
> > 	write combining feature.  These need to be in a separate
> > 	granule from regular memory to prevent the FSB from having
> > 	both a cached and an uncached reference to a memory location.
> > 
> > sgi_cached) Provides a device which support cached operations from the
> > 	processor and uncached from processors outside the coherence
> > 	domain.  This provides rapid read access to the 16 words in the
> > 	cache line to data that was written uncached by remote processors.
> 
From your description only the first two actually use special SGI hardware
> features, or did I misread the descruption?  If so they should probably
> have a separate driver that works on all ia64 hardware.

I am not sure how to read this.  The fetchop function is a feature specifically
in the SN2 memory controller.  Are you saying we should have a driver that
provides fetchops for all ia64?  That seems wrong since it is a hardware feature.

If, on the other hand, you are saying that the uncached and cached drivers
should be available for all ia64 and the fetchop only if you are on sn2, I
can understand that.  That actually seems rather reasonable.

Would anybody else on ia64 be interested in either the uncached or cached
features?  The cached is really there to support MPI communications across
the coherence domain.  Does anybody else have a NUMA architecture which
mixes cache coherent and non-coherent NUMA?  If not, I don't think that
the cached functionality would ever be preferrable over regular cached
references.

Robin

  parent reply	other threads:[~2004-09-09 17:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-09 16:36 [RFC 0/4] Add SN2 Special Memory driver Robin Holt
2004-09-09 17:21 ` Christoph Hellwig
2004-09-09 17:59 ` Robin Holt [this message]
2004-09-10  7:33 ` Christoph Hellwig
2004-09-10  8:31 ` Robin Holt
2004-09-10  8:32 ` Christoph Hellwig
2004-09-10 15:34 ` Jesse Barnes

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=20040909175937.GC23863@lnx-holt.americas.sgi.com \
    --to=holt@sgi.com \
    --cc=linux-ia64@vger.kernel.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