vmalloc limits in PPC kernels ?

Matt Porter porter at cox.net
Sat Feb 15 04:49:29 EST 2003

On Fri, Feb 14, 2003 at 11:32:44AM -0600, vinai wrote:
> Matt,
> Thanks much for the information you provided below.  Are there any
> pointers/references as to why these changes were actually implemented,
> or is it really a case of "the source being the guide" ?  As I said,
> this issue is really troubling for us, and I want to see if there is
> a "clean" way to circumvent that limit without screwing up the MM
> subsystem (at least not too badly :) ...

No docs beyond mailing list archives (for x86, lkml. for ppc,
-dev/-embedded/#mklinux).  Use the source.

x86's reasons for changes are off-topic here. :) I think you'll
find out that much of the reason had to do with the the transition
from various bigmem hacks to the current highmem solution for large
system memory.  This transition caused i386 to rework their limits
around the pkmap pool for one.  They probably also made their usual
choices around trying to be targetted at the mid-level of ia32

It's the same thought process that goes into the PPC VM defaults.
The difference is that we have developers that consciously worry
about common embedded application usage.  That led to the VM
tweaking options.

Matt Porter
porter at cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

More information about the Linuxppc-dev mailing list