Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Improving <strong>Kernel</strong> Performance by Unmapping the<br />
Page Cache<br />
James Bottomley<br />
SteelEye Technology, Inc.<br />
James.Bottomley@SteelEye.com<br />
Abstract<br />
<strong>The</strong> current DMA API is written on the founding<br />
assumption that the coherency is being<br />
done between the device and kernel virtual addresses.<br />
We have a different API for coherency<br />
between the kernel and userspace. <strong>The</strong> upshot<br />
is that every Process I/O must be flushed twice:<br />
Once to make the user coherent with the kernel<br />
and once to make the kernel coherent with the<br />
device. Additionally, having to map all pages<br />
for I/O places considerable resource pressure<br />
on x86 (where any highmem page must be separately<br />
mapped).<br />
We present a different paradigm: Assume that<br />
by and large, read/write data is only required<br />
by a single entity (the major consumers of large<br />
multiply shared mappings are libraries, which<br />
are read only) and optimise the I/O path for this<br />
case. This means that any other shared consumers<br />
of the data (including the kernel) must<br />
separately map it themselves. <strong>The</strong> DMA API<br />
would be changed to perform coherence to the<br />
preferred address space (which could be the<br />
kernel). This is a slight paradigm shift, because<br />
now devices that need to peek at the data may<br />
have to map it first. Further, to free up more<br />
space for this mapping, we would break the assumption<br />
that any page in ZONE_NORMAL<br />
is automatically mapped into kernel space.<br />
<strong>The</strong> benefits are that I/O goes straight from<br />
the device into the user space (for processors<br />
that have virtually indexed caches) and the kernel<br />
has quite a large unmapped area for use in<br />
kmapping highmem pages (for x86).<br />
1 Introduction<br />
In the <strong>Linux</strong> kernel 1 there are two addressing<br />
spaces: memory physical which is the location<br />
in the actual memory subsystem and CPU virtual,<br />
which is an address the CPU’s Memory<br />
Management Unit (MMU) translates to a memory<br />
physical address internally. <strong>The</strong> <strong>Linux</strong> kernel<br />
operates completely in CPU virtual space,<br />
keeping separate virtual spaces for the kernel<br />
and each of the current user processes. However,<br />
the kernel also has to manage the mappings<br />
between physical and virtual spaces, and<br />
to do that it keeps track of where the physical<br />
pages of memory currently are.<br />
In the <strong>Linux</strong> kernel, memory is split into zones<br />
in memory physical space:<br />
• ZONE_DMA: A historical region where<br />
ISA DMAable memory is allocated from.<br />
On x86 this is all memory under 16MB.<br />
• ZONE_NORMAL: This is where normally<br />
allocated kernel memory goes. Where<br />
1 This is not quite true, there are kernels for processors<br />
without memory management units, but these are<br />
very specialised and won’t be considered further