From: "Dave Airlie" <airlied@gmail.com>
To: "Andi Kleen" <ak@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
"Linus Torvalds" <torvalds@osdl.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: GFP_DMA32 and PAE x86 machines
Date: Thu, 31 May 2007 09:09:58 +1000 [thread overview]
Message-ID: <21d7e9970705301609w88a9f80t20f83806003f699e@mail.gmail.com> (raw)
In-Reply-To: <200705310024.25937.ak@suse.de>
On 5/31/07, Andi Kleen <ak@suse.de> wrote:
> On Thursday 31 May 2007 00:07:45 Dave Airlie wrote:
> > Depending on split all lowmem is below 1GB which isn't exactly
> > optimal, I'd llike all 4GB for DMA.
>
> Well it would be for a quite specialized limited use case:
> - Memory the kernel doesn't need to map (after all kmap is evil)
> - You need more than 500MB or so.
> - 32bit kernel and user cannot run 64bit kernel
> - Machine has >3GB of RAM
>
> Is there clear evidence that is a common issue? If it is just a "would
> be nice to have in theory" the cost of doing a GFP_DMA32 for i386 would be
> probably not worth doing it. If it's a common issue it might be
> considered, although the "here's a nickle. buy yourself a 64bit CPU"
> strategy would also sound attractive.
>
> Please give a very very strong rationale why you want it. Did you actually
> run into such a situation yourself yet?
Funnily enough I have just today with an app I have which uses 1.2GB
of textures :-)
we are currently using GFP_DMA32 in the TTM allocator code, however
what I really want on x86 non-PAE is GFP_HIGHMEM (as DMA32 does
nothing) however on x86-PAE I don't want that I want a real GFP_DMA32,
and on x86-64 I want the current GFP_DMA32,
Therein lies my problems, the API sucks, but I suppose the DRM TTM is
a special use case (AGP is the same) and I'll accept the fact that can
just make it my own problem, my current solution would be to screw PAE
machines giving them 1GB only and let non-PAE access all 4GB.
Dave.
next prev parent reply other threads:[~2007-05-30 23:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-30 21:10 Dave Airlie
2007-05-30 21:29 ` H. Peter Anvin
2007-05-30 22:07 ` Dave Airlie
2007-05-30 22:13 ` H. Peter Anvin
2007-05-30 22:24 ` Andi Kleen
2007-05-30 22:31 ` H. Peter Anvin
2007-05-30 23:09 ` Dave Airlie [this message]
2007-05-30 23:21 ` William Lee Irwin III
2007-05-31 12:11 ` 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=21d7e9970705301609w88a9f80t20f83806003f699e@mail.gmail.com \
--to=airlied@gmail.com \
--cc=ak@suse.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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
all inboxes | Powered by JetHome®