Kernel functions

You'll find two types of kernel routines dealing with memory. The first set contains all the functions that implement the kernel's version of malloc() ” "give me some space." These functions keep a kernel free memory list and expand the kernel's data space (and physical size ) as necessary. These functions deal with the kernel's need for more memory and have nothing to do with a user program's memory requests .

The other type of function deals with setting up virtual address mappings for user processes: keeping track of their address space, handling page faults, and dealing with swapping and anonymous memory. We'll deal with them in a moment; first, let's look at the various versions of handling the kernel's requirement for memory. This will not be an in-depth treatment but will briefly cover the functions and their purpose so that you can recognize the names when you see them.

malloc(): SunOS 4.x

There are some differences between the OS version of malloc() , although the end result is the same. In the SunOS 4.x kernel, there are two distinct methods of requesting or allocating memory inside the kernel's address space, depending on what you're going to use it for. One method will just take pages as necessary and add them to kernel space. This method attaches the new pages to the kernel address space in an area known as the heap . The heap is "generic" memory: it can be used for anything. Most commonly, it is used for data structures that are dynamically allocated as the kernel needs them. These memory requests will fail if there are no pages on the free list and the kernel can't wait around for some to become available.

The other method of memory allocation uses "resource maps," which define a range of virtual addresses intended for a specific purpose: the kernel pulls a chunk from a map of already allocated and locked-down memory. For these allocations , running out of space is usually an error, and the request will fail. The space used for mbufs , for example, is a fixed size. When the system runs out of memory for network data buffers, you will see error messages on the console and the system will probably start losing incoming data.

What are resource maps? A map is a low-level kernel structure used to keep track of things. It is intended to hold a list of free space for some particular resource. (The map structure is defined in the header file /usr/include/sys/map.h ). In 4.x, resource maps are used for describing kernel virtual address space, performing mbuf allocations, keeping track of swap space, and DVMA (I/O direct to memory) operations, among others. There may actually be higher-level functions that perform the act of allocation, but these routines will keep track of the data with resource maps. Each of these maps consists of a fixed-length array of structures describing a range of free space, which may correspond to actual memory, disk blocks, or a set of unused structures. In fact, the map may be used for units of bytes, pages, or disk blocks. The maps themselves , the arrays, are set up at boot time, although the space they keep track of may not have been allocated yet.

The resource map contents (the array entries) are handled by two functions, rmalloc() and rmfree() . These routines deal with arbitrary maps, since they are all in the same format, so for any stack tracebacks or panics that involve these functions you will need to discover which map is being processed . Resource allocation can fail (or hang) for a couple of reasons: Either the map is empty (the resource is completely exhausted) or it has become so fragmented that there is nothing big enough to satisfy the request. In fact, if a new bit of free space has to be added in to an already badly fragmented map, there may not be any place to put that information: The array could be full. In this case, a message is printed on the console ("rmap overflow") and that bit of free space is thrown away. It can only be recovered and reused by rebooting the system.

One of the kernel maps describes the range of memory known as heap space . The heap functions work just like a user-level malloc() . If a request can be satisfied from a list of free (available) memory that already belongs to the kernel, that memory will be "recycled." If more memory is needed, then new pages are obtained from the system free page list and inserted into the kernel heap space by being added to the resource map.

If there is memory in the free list, it is kept in a special form (a tree structure), so there are some special functions that deal with getting free memory from the heap:

• kmem_alloc() ” Returns a pointer to an allocated block of memory (or a null, if the request failed).

• new_kmem_alloc() ” Is essentially the same but takes an additional parameter. In fact, kmem_alloc() calls new_kmem_alloc() . The additional parameter is a flag that tells the function whether it can wait (sleep) if memory is not available.

• kmem_zalloc() ” The same as kmem_alloc() with a bzero() call added to clear the memory to zeroes.

• new_kmem_zalloc() ” new_kmem_alloc() with a bzero.

You may also see some very similar but separate routines that grab space from different small pools of memory. These pools each keep their own free list, which is not based on a map structure; the functions are intended to provide a faster allocation method for specific, dedicated memory areas. These functions correspond to the above list and have very similar names:

• kmem_fast_alloc()

• new_kmem_fast_alloc()

• kmem_fast_zalloc()

• new_kmem_fast_zalloc()

Although their purpose is similar to the whole idea behind resource maps, the functions are not implemented the same way. All in all, many different but very similar routines manipulate memory. A lot of consolidation was performed in Solaris 2 to eliminate some of this confusion.

malloc(): Solaris 2

Many of the same routine names have been kept in Solaris 2 for compatibility, but the allocation scheme behind the names is substantially different. There are still resource maps, but the heap in its original form is gone; there are now pools of memory with chunks of various sizes that are used for general purpose memory allocation. The pools are filled when needed by pages grabbed from the free list. Plus, in a radical turnabout , excess free pages are actually returned to the system free page list!

kmem_alloc() , kmem_zalloc() , and kmem_free() are defined in the list of kernel support functions known as the DDI/DKI (section 9F in the manual pages). These routines behave to the outside just as they did in 4.x: a size in bytes is requested , a flag will indicate whether the caller can wait (sleep) for the request, and either a pointer to the memory space or a null is returned. There are internal differences corresponding to the new organization of free memory.

The new lower-level functions kmem_allocspool() (to control the "small" buffer pool) and kmem_allocbpool() (for the "big" buffer pool) are routines to add to the available pools of free buffers if it becomes necessary. These functions request chunks of memory and split them up. Small buffers are chunks of memory from 8 bytes up to 256 bytes in length. Big buffers range from 512 bytes up to 16 kilobytes in length. Buffers are maintained in lengths that are powers of two; each level up is twice the size of the previous level. If a request for a particular size cannot be filled, a larger buffer (the next size up) will be requested and split in half: one half going to the requestor , the other back to the free pool. If no memory is available all the way up the chain, a call to kmem_getpages() will grab pages from the free list, perform a call to rmalloc() to allocate kernelmap (page table) entries, and add the new kernel pages to the buffer pool.

Resource maps are still around in Solaris 2. The map structure itself is different, and there are fewer maps in the kernel. Some maps are set up at boot time, and others are built dynamically when the appropriate module is loaded. Refer to the header file /usr/include/sys/map.h for the definitions.