Re: GFP_DMA32 and PAE x86 machines

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/31/07, Andi Kleen <[email protected]> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux