Kernel Memory Allocation

How kernel memory is allocated and may be controlled in a vPar PA-RISC environment
III. How the Virtual Partition Monitor allocates memory
As each vPar's kernel is loaded, the monitor will first look at the kernel size and in 64MB chunks with vPars
A.03 and in whatever the granularity size is with vPars A.04 and A.05, allocate memory from the lower
2GB address space. The monitor will then allocate the rest of the requested memory for the vPar from the
upper memory address space. This happens for each vPar, first using lower memory for its kernel, then
using upper memory for the rest of the vPar's memory request. Essentially, the memory address space is
being used up towards the middle but more quickly from the upper memory since this is where the bulk of
the memory requested is coming from.
What you will also find is that using the process above, the vPar monitor ends up assigning very little of the
lower 2GB address space to the first, second, and so on vPars and it isn't until the last vPar that the bulk of
the lower 2GB of memory is assigned to that last vPar (assuming you assign all the memory in the
system/nPar). So basically it is the last vPar loaded that owns most of the lower 2GB memory simply
because it is used up last in the overall memory allocation process.
The memory allocation process can be summed up by the following steps:
1. Allocate memory in 64MB contiguous chunks in the lower 2GB memory for first vpars kernel and upper
memory for the remaining memory required for the vPar. Repeat this until all of the upper memory is used
or all lower memory is used.
2. If all upper memory is used, begin allocating in lower memory.
3. If all lower memory is used (ie. No 64 MB contiguous chunks of lower memory availalble for kernel),
the vPar will fail to load.
IV.
The Problem Definition
As explained above, you must make sure that all of the vPars’ kernels will fit within the lower 2GB address
space (i.e. all the kernel sizes added up are less than 2GB) and each kernel will fit in contiguous memory
space and that you have enough memory in the system to accommodate not only all the kernel space but
the rest of the memory requirements for each vPar.
So, assuming you meet the basic condition above the vPar monitor does its memory allocation process and
each vPar is loaded using memory for its kernel from the lower 2GB address space and then the rest of its
memory from the upper address space and everything loads just fine.
The basic version of the problem is when there isn’t enough lower 2GB memory address space to load
kernels. Let’s look at two cases of how this can happen.
A. What if a kernel change is needed on one of the vPars that is booted or you
want to create additional vPars and you have used/assigned all the memory in
the system/nPar?
Page 2 of 5