lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <21d7e9970705301609w88a9f80t20f83806003f699e@mail.gmail.com>
Date:	Thu, 31 May 2007 09:09:58 +1000
From:	"Dave Airlie" <airlied@...il.com>
To:	"Andi Kleen" <ak@...e.de>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	"Linus Torvalds" <torvalds@...l.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: GFP_DMA32 and PAE x86 machines

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ