Some memory management/allocation stuff.
[cascardo/kernel/old_slides/.git] / 05.memory / 05.memory.xml
diff --git a/05.memory/05.memory.xml b/05.memory/05.memory.xml
new file mode 100644 (file)
index 0000000..6b5f73a
--- /dev/null
@@ -0,0 +1,132 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE slides SYSTEM "/usr/share/xml/docbook/custom/slides/3.3.1/schema/dtd/slides-full.dtd">
+
+<slides>
+
+<slidesinfo>
+<title>Memory Management</title>
+<author><firstname>Thadeu</firstname><surname>Cascardo</surname></author>
+</slidesinfo>
+
+<foil>
+<title>Introduction</title>
+<itemizedlist>
+<listitem>
+Kernel space has small stack, in the order of one or two small pages.
+</listitem>
+<listitem>
+Memory allocation must be efficient in big SMP systems.
+</listitem>
+<listitem>
+Memory protection and virtualization is done through paging.
+</listitem>
+<listitem>
+The slab allocator has multiple implementations: SLAB, SLUB, SLOB and SLQB.
+</listitem>
+</itemizedlist>
+</foil>
+
+<foil>
+<title>kmalloc/kfree</title>
+<itemizedlist>
+<listitem>
+kmalloc and kfree are equivalent parts for malloc and free from user space, but
+for a flags parameter in kmalloc.
+</listitem>
+<listitem>
+The flags parameter depends on the context, which we'll see and revise next.
+Default usage should be GFP\_KERNEL.
+</listitem>
+<listitem>
+The slab allocator implements kmalloc.
+</listitem>
+</itemizedlist>
+</foil>
+
+<foil>
+<title>More about kmalloc</title>
+<itemizedlist>
+<listitem>
+Allocated memory by kmalloc is contiguous in physical memory.
+</listitem>
+<listitem>
+It does not clear memory, use kzalloc for that.
+</listitem>
+<listitem>
+kzfree has been introduced recently, in 2.6.29.
+</listitem>
+</itemizedlist>
+</foil>
+
+<foil>
+<title>Lookaside Caches</title>
+<itemizedlist>
+<listitem>
+For efficient allocation of many objects of a predefined size, use lookaside
+caches.
+</listitem>
+<listitem>
+You should use <emphasis>kmem\_cache\_create</emphasis> to allocate a
+<emphasis>kmem\_cache\_t</emphasis>. It has a name, an object size, alignment,
+flags and a constructor.
+</listitem>
+<listitem>
+The destructor parameter has been removed, since 2.6.27.
+</listitem>
+<listitem>
+It is destroyed with <emphasis>kmem\_cache\_destroy</emphasis>.
+</listitem>
+</itemizedlist>
+</foil>
+
+<foil>
+<title>Using lookaside caches</title>
+<itemizedlist>
+<listitem>
+Use it with <emphasis>kmem\_cache\_alloc</emphasis> and release the object with
+<emphasis>kmem\_cache\_free</emphasis>.
+</listitem>
+</itemizedlist>
+</foil>
+
+<foil>
+<title>Lookaside cache example</title>
+<screen>
+</screen>
+</foil>
+
+<foil>
+<title>vmalloc</title>
+<itemizedlist>
+<listitem>
+For large sizes of memory, vmalloc should be used. However, it does not allocate
+a contiguous physical memory range.
+</listitem>
+<listitem>
+Use vfree to release this memory.
+</listitem>
+<listitem>
+vmalloc get many memory pages and map them to a contiguous virtual memory range.
+However, this virtual memory address is in a differente range from that used by
+kmalloc and other allocation functions.
+</listitem>
+</itemizedlist>
+</foil>
+
+<foil>
+<title>Per-CPU variables</title>
+<itemizedlist>
+<listitem>
+Sometimes it is best to use one variable per CPU to avoi some concurrency.
+</listitem>
+<listitem>
+Define the variable using <emphasis>DEFINE\_PER\_CPU</emphasis> macro.
+</listitem>
+<listitem>
+The pair <emphasis>get\_cpu\_var</emphasis> and
+<emphasis>put\_cpu\_var</emphasis> must be used to access these variables.
+</listitem>
+</itemizedlist>
+</foil>
+
+</slides>