From: Terence Ripperda <tripperda@nvidia.com>
To: Andi Kleen <ak@suse.de>
Cc: Terence Ripperda <tripperda@nvidia.com>, Andi Kleen <ak@muc.de>,
discuss@x86-64.org, tiwai@suse.de, linux-kernel@vger.kernel.org,
andrea@suse.de
Subject: Re: [discuss] Re: 32-bit dma allocations on 64-bit platforms
Date: Thu, 24 Jun 2004 17:28:57 -0500 [thread overview]
Message-ID: <20040624222857.GM615@hygelac> (raw)
In-Reply-To: <20040624161539.GC8085@wotan.suse.de>
On Thu, Jun 24, 2004 at 09:15:40AM -0700, ak@suse.de wrote:
> I would prefer if the default value would work for most users
> because any special options are a very high support load.
> Do you think 64MB (minus other users so maybe 30-40MB in practice)
> would be still sufficient to give reasonable performance without
> hickups?
that's what we're currently asking users to do for our current swiotlb
code. we are seeing some hickups in ut2004, but I haven't investigated
if this is related to limited memory resources (actually, it shouldn't
be, as we'd have paniced instead of failing to allocate memory).
I think I would push for 128M by default, just to make sure there's
plenty. I don't think this should be too bad, since this would only
kick in if the user has 4+ Gigs of memory, in which 128M is a small
portion of the total.
> Agreed, the panics should be made optional at least. I will
> take a look at doing this for swiotlb too. I like
> them as options though because for debugging it's better to get
> a clear panic than a weird malfunction.
it makes perfect sense to have a debugging option for that, it'd just
be nice to have that not be the default.
> But why didn't you implement addressing capability for >32bit
> in your hardware then? I imagine the memory requirements won't
> stop at 4GB (or rather 2-3GB because not all phys mapping
> space below 4GB can be dedicated to graphics)
I suspect the addressing capability is due to cost/die size tradeoffs.
and I didn't mean to imply that these setups would be common, or
really use that much additional memory. just pointing out that it's
not uncommon to have some odd frankenstein setups that would use a
little more memory than normal. you are correct that in these cases, a
little more end user tweaking is acceptable.
after talking to some of the other developers here, we wanted to
re-inquiry about the extra dma zone approach, and how
feasible/acceptable that might be. one of the thoughts is that the
swiotlb approach would probably be the easiest to get in place
quickly, but that the dma zone approach would be more robust.
we wouldn't need to set aside an allocation pool, there wouldn't need
to be end user tweaking for the corner cases, etc..
Thanks,
Terence
next prev parent reply other threads:[~2004-06-24 22:33 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <m3acyu6pwd.fsf@averell.firstfloor.org>
[not found] ` <20040623213643.GB32456@hygelac>
2004-06-23 23:46 ` 32-bit dma allocations on 64-bit platforms Andi Kleen
2004-06-24 11:13 ` Takashi Iwai
2004-06-24 11:29 ` [discuss] " Andi Kleen
2004-06-24 14:36 ` Takashi Iwai
2004-06-24 14:42 ` Andi Kleen
2004-06-24 14:58 ` Takashi Iwai
2004-06-24 15:29 ` Andrea Arcangeli
2004-06-24 15:48 ` Nick Piggin
2004-06-24 16:52 ` Andrea Arcangeli
2004-06-24 16:56 ` William Lee Irwin III
2004-06-24 17:32 ` Andrea Arcangeli
2004-06-24 17:38 ` William Lee Irwin III
2004-06-24 18:02 ` Andrea Arcangeli
2004-06-24 18:13 ` William Lee Irwin III
2004-06-24 18:27 ` Andrea Arcangeli
2004-06-24 18:50 ` William Lee Irwin III
2004-06-24 21:54 ` Andrew Morton
2004-06-24 22:08 ` William Lee Irwin III
2004-06-24 22:45 ` Andrea Arcangeli
2004-06-24 22:51 ` William Lee Irwin III
2004-06-24 23:09 ` Andrew Morton
2004-06-24 23:15 ` William Lee Irwin III
2004-06-25 6:16 ` William Lee Irwin III
2004-06-25 2:39 ` Andrea Arcangeli
2004-06-25 2:47 ` Andrew Morton
2004-06-25 3:19 ` Andrea Arcangeli
2004-06-24 22:11 ` Andrew Morton
2004-06-24 23:09 ` Andrea Arcangeli
2004-06-25 1:17 ` Nick Piggin
2004-06-25 3:11 ` Andrea Arcangeli
2004-06-24 22:21 ` Andrea Arcangeli
2004-06-24 22:36 ` Andrew Morton
2004-06-24 23:15 ` Andrea Arcangeli
2004-06-24 22:37 ` William Lee Irwin III
2004-06-24 22:40 ` William Lee Irwin III
2004-06-24 23:21 ` Andrea Arcangeli
2004-06-24 23:45 ` William Lee Irwin III
2004-06-24 17:39 ` Andrea Arcangeli
2004-06-24 17:53 ` William Lee Irwin III
2004-06-24 18:07 ` Andrea Arcangeli
2004-06-24 18:29 ` William Lee Irwin III
2004-06-24 16:04 ` Takashi Iwai
2004-06-24 17:16 ` Andrea Arcangeli
2004-06-24 18:33 ` Takashi Iwai
2004-06-24 18:44 ` Andrea Arcangeli
2004-06-25 15:50 ` Takashi Iwai
2004-06-25 17:30 ` Andrea Arcangeli
2004-06-25 17:39 ` Takashi Iwai
2004-06-25 17:45 ` Andrea Arcangeli
2004-06-24 14:45 ` Terence Ripperda
2004-06-24 15:41 ` Andrea Arcangeli
2004-06-24 15:44 ` Terence Ripperda
2004-06-24 16:15 ` [discuss] " Andi Kleen
2004-06-24 17:22 ` Andrea Arcangeli
2004-06-24 22:28 ` Terence Ripperda [this message]
2004-06-24 18:51 ` Andi Kleen
2004-06-26 4:58 ` David Mosberger
2004-06-24 13:48 Jesse Barnes
2004-06-24 14:39 ` Terence Ripperda
2004-06-24 15:01 ` [discuss] " Andi Kleen
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=20040624222857.GM615@hygelac \
--to=tripperda@nvidia.com \
--cc=ak@muc.de \
--cc=ak@suse.de \
--cc=andrea@suse.de \
--cc=discuss@x86-64.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tiwai@suse.de \
/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