In order to truly test page allocation, we published a scullp with other examples of code modules. It is a simplified scull, as described earlier scullc.
Memory allocation is an integer quantum scullp page or set of pages: scullp_order Variable Default is 0, but may be changed at compile time or load.
The following lines show how it allocates memory:
/* Here's the allocation of a single quantum */ if (!dptr->data[s_pos])
{
dptr->data[s_pos] =
Although alloc_pages (described later) should really be used as high memory page allocation, for some reason we really involved until Chapter 15.
(void *) get_free_pages(GFP_KERNEL, dptr->order); if (!dptr->data[s_pos])
Got to fade;
memset(dptr->data[s_pos], 0, PAGE_SIZE << dptr->order);
}
scullp release code memory seems so:
/* This code frees a whole quantum-set */ for (i = 0; i < qset; i++)
if (dptr->data[i])
free_pages((unsigned long)(dptr->data[i]), dptr->order);
At the user level, the perceived difference is primarily a speed improvement and better memory use, because there is no internal memory fragmentation we run some tests scull0 copies from 4 MB to scull1, and then from scullp0 to scullp1;. The results show in kernel space processor usage has increased slightly.
Improved performance is not exciting, because kmalloc is designed to be fast. The main advantage of page-level allocation is not actually speed, but more efficient memory usage. Allocation by page without wasting memory, while using kmalloc since the particle size distribution will waste can not predict the amount of memory.
But the biggest advantage get_free_page page function is obtained entirely yours, and you can, in theory, can be a combination of these pages as a linear area by appropriate settings page tables. For example, you can allow a user process to mmap as a single contact page is not obtained memory area. this operation we discuss in Chapter 15, where we show how to provide scullp memory mapping, something some of the scull can not provide.