首先我提几个主题：
磁盘高速缓存、内存高速缓存、硬件高速缓存、每cpu页框高速缓存、页高速缓存、目录项高速缓存、索引节点高速缓存、转换后援缓冲器（TLB）、哈佛结构的高速缓存、写缓冲器、高速缓存一致性、L1和L2等高速缓存在驱动的使用。
上面这些就我在接下来的文章中要讨论的东西。如果您对上面的东西了如指掌，真心希望您能给本屌丝指点指点。
高速缓存大家喜欢叫cache。对于嵌入式的观众，第一反应可能是arm中常提到的dcache、icache。如果你意识到这个；恭喜你！你已经看见哈佛结构的高速缓存了同时明白了硬件高速缓存。对于这样的认识，只是在硬件层，本身哈佛结构就是硬件层的话题。但是我的所有讨论都是在linux环境下，那么linux中提到的高速缓存是什么？(下面代码参考linux-3.2.8)
下面我们讨论由软件机制构造出的高速缓存。（自备饮料、爆米花和3D眼镜）
1.每CPU页框高速缓存。
内核经常请求和释放单个页框。为了提升系统性能，每个内存管理区定义了一个“每CPU”页框高速缓存。所有“每CPU”高速缓存包含一些预先分配的页框。
这个高速缓存分为两个缓存，一个是热高速缓存，它存放的页框中所包含的的内容很可能就在cpu硬件高速缓存中。;另一个是冷高速缓存。
对于这两个的管理，很多文章说有两个per_cpu_pages描述符组成。不过在我在linux-3.2.8中看到只用了一个，简单看一下：
struct per_cpu_pages *pcp;
struct list_head *list;
//…省略代码
list =&pcp->lists[migratetype];
//…省略代码
if (cold)
page =list_entry(list->prev, struct page, lru);
else
page =list_entry(list->next, struct page, lru);
看一下这个描述符：
struct per_cpu_pages {
int count; /* number of pages in the list */
int high; /* high watermark, emptyingneeded */
int batch; /* chunk size for buddy add/remove*/
/* Lists of pages, oneper migrate type stored on the pcp-lists */
struct list_headlists[MIGRATE_PCPTYPES];
};
ULK的原话：
内核使用两个位标来监视热高速缓存和冷高速缓存的大小：如果页个数低于下界low，内核通过buddy系统分配batch个单一页面来补充对应的高速缓存；否则，如果页框个数高过上界high，内核从高速缓存中释放batch个页框到buddy系统中。
你可以看到我的per_cpu_pages中更本就没有low，之前看到一位有专家标签的csdn博主，和我贴出一样的struct per_cpu_pages却直接引用了ULK的原话！！！
我们看看linux-3.2.8中是怎么判断的：
list =&pcp->lists[migratetype];
if(list_empty(list)) {
pcp->count += rmqueue_bulk(zone, 0,
pcp->batch, list,
migratetype, cold);
这样就相当于曾经的low=0。
batch、high的值是初始化调用setup_pageset()计算的，和内存大小有关。
buffered_rmqueue()函数在指定的内存管理区中分配页框。它使用每CPU页框高速缓存来处理单一页框请求。记得之前的__alloc_pages()吧，它就存在一个过程：
alloc_pages()->alloc_pages_node()->__alloc_pages()->__alloc_pages_nodemask()->get_page_from_freelist()->buffered_rmqueue()
只贴出部分代码:
static inline
struct page*buffered_rmqueue(struct zone *preferred_zone,
struct zone *zone, intorder, gfp_t gfp_flags,
int migratetype)
{
unsigned long flags;
struct page *page;
int cold = !!(gfp_flags &__GFP_COLD);//冷热判断。
if (likely(order == 0)) {//上面提到：“内核经常请求和释放单个页框”，单个页框请求是使用每CPU页框高速缓存的条件。
struct per_cpu_pages *pcp;
struct list_head *list;
local_irq_save(flags);
pcp =&this_cpu_ptr(zone->pageset)->pcp;
list =&pcp->lists[migratetype];
if (list_empty(list)) {//空就就要增加
pcp->count +=rmqueue_bulk(zone, 0,
pcp->batch, list,
migratetype, cold);
if(unlikely(list_empty(list)))
goto failed;
}
//下面根据冷热取
if (cold)
page =list_entry(list->prev, struct page, lru);
else
page =list_entry(list->next, struct page, lru);
list_del(&page->lru);
pcp->count--;//减去取出的
} else {//这下面是调用__rmqueu()函数从伙伴系统中分配所请求的页框
//…
page = __rmqueue(zone, order,migratetype);
//…
}
}
提速的根本：
如果pcp->lists[migratetype]不是NULL，那么获取页框只是从这个list中获取一个元素。而不用利用__rmqueue()去请求。
最后再说一句，每CPU页框高速缓存只限于单一页框。
2.内存高速缓存
在ldd3中我们就看到了后备缓存的概率，linux内核的缓存管理者有时称为“slab分配器”，如果驱动中要频繁请求内存，可以考虑使用这个slab分配器去做。slab分配器把那些 页框保存在高速缓存中并很快地重新使用它们。
这个和上面说的每CPU页框高速缓存的目的都是绕过内核内存分配器。
每个高速缓存的描述符是kmem_cache_t，kmem_cache_t对应多了slab，每个slab由一个或多了连续的页框组成。
对于这个slab，在ldd3中或者网上有很多的应用示例，我就不多说了。