public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: [Linux-ia64] Re: PCI DAC routines for SN
Date: Thu, 25 Apr 2002 00:11:19 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590701905518@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590701905493@msgid-missing>

On Wed, Apr 24, 2002 at 04:53:31PM -0700, David S. Miller wrote:
>    From: Jesse Barnes <jbarnes@sgi.com>
>    Date: Wed, 24 Apr 2002 16:13:08 -0700
>    
>    So the penalty for using DAC comes down to ~.0375% for a 64k I/O, and
>    the benefit is that you don't have to use 32 bit mappings (which can
>    be scarce on some platforms).
> 
> No some, _your_ platform.   It is the only one with this problem.

Right, the platform that I'd like to see work well.

> You only need this 4GB memory for consistent memory, not
> for anything else!  %99 of the kernel is going to use memory
> for pages and data, not descriptors.
> 
> You can use zones and whatnot to make sure this isn't a problem at
> all.

I think you're confusing our platform with generic ia64 platforms.
I'm not worried about allocating in the low 4GB or whatever, I'm
concerned about using 32 bit mappings needlessly.  Of course, generic
ia64 boxes would also benefit...

So if performance isn't an obstacle to implementing a new call, and
I've shown that there are platforms where 64 bit consistent mappings
are better to use than 32 bit mappings when possible, why can't we add
it?  Or maybe just a seperate consistent_mask that drivers could set
to indicate they support the operation and let the platform take care
of it?

Thanks,
Jesse


  parent reply	other threads:[~2002-04-25  0:11 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-22 22:34 [Linux-ia64] Re: PCI DAC routines for SN David Mosberger
2002-04-22 22:39 ` Jesse Barnes
2002-04-22 23:07 ` David Mosberger
2002-04-22 23:40 ` Jesse Barnes
2002-04-23  1:34 ` Grant Grundler
2002-04-23 21:11 ` Grant Grundler
2002-04-24  4:04 ` David S. Miller
2002-04-24  5:49 ` Jesse Barnes
2002-04-24  5:50 ` David S. Miller
2002-04-24 16:13 ` Grant Grundler
2002-04-24 17:39 ` David S. Miller
2002-04-24 17:40 ` David S. Miller
2002-04-24 19:45 ` Jesse Barnes
2002-04-24 23:13 ` Jesse Barnes
2002-04-24 23:53 ` David S. Miller
2002-04-25  0:08 ` David S. Miller
2002-04-25  0:11 ` Jesse Barnes [this message]
2002-04-25  0:17 ` David S. Miller
2002-04-25  0:21 ` Jesse Barnes
2002-04-25  0:36 ` Jesse Barnes
2002-04-25  0:43 ` David S. Miller
2002-04-25  1:00 ` David S. Miller
2002-04-25  1:01 ` Jesse Barnes
2002-04-25  1:22 ` 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=marc-linux-ia64-105590701905518@msgid-missing \
    --to=jbarnes@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