[lkml]   [2002]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: consequences of lowering "MAX_LOW_MEM"?
On Wed, Sep 04, 2002 at 10:02:27PM +0200, Benjamin Herrenschmidt wrote:
> >
> >> >I think you'll find yourself with no virtual address space left to
> >> >do vmalloc / fixmap / kmap type stuff. Or at least you would on i386,
> >> >I presume it's the same for ppc. Sounds like you may have left
> >> >yourself enough space for fixmap & kmap, but any calls to vmalloc
> >> >will probably fail ?
> >>
> >> Yes, same problem on PPC, you'll run out of virtual space quite
> >> quickly for vmalloc and ioremap. Stuff a video board with lots
> >> of VRAM or any PCI card exposing large MMIO regions into your
> >> machines and it will probably not even boot.
> >>
> >> Ben.
> >>
> >
> >Ben,
> > But doesn't using Matt's suggestion and moving both MAX_LOW_MEM and
> >changing KERNELBASE take care of this? It's an embedded board with no
> >video, but it does have one PCI Mezzanine Card (PMC) on it.
> Yes, Matt's suggestion would work, though I never tried lowering
> KERNELBASE. I don't think the kernel supports lowering it below
> 0x80000000 btw.

Take a look at those options. :) I added one to tweak TASK_SIZE
from the PPC default of 0x80000000.

I've run a system with a TASK_SIZE of 1GB, MAX_LOW_MEM at 16MB,
PAGE_OFFSET at 0x40000000, and HIGHMEM on with the PKMAP_BASE
placed up higher than the default 0xfe000000 (with a 1GB of RAM
installed) to allow for close to 3GB of vmalloc space. Certain
embedded systems with large PCI windows (like non-transparent
bridges, for example) gobble up vmalloc space pretty darn quickly.
This is just getting worse with RapidIO on a 32-bit processor.

Matt Porter
This is Linux Country. On a quiet night, you can hear Windows reboot.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.042 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site