写一个块设备驱动13，14
http://blogold.chinaunix.net/u3/108239/showart.php?id=2144636
第13章
+---------------------------------------------------+
| 写一个块设备驱动 |
+---------------------------------------------------+
| 作者：赵磊 |
| email: zhaoleidd@hotmail.com |
+---------------------------------------------------+
| 文章版权归原作者所有。 |
| 大家可以自由转载这篇文章，但原版权信息必须保留。 |
| 如需用于商业用途，请务必与原作者联系，若因未取得 |
| 授权而收起的版权争议，由侵权者自行负责。 |
+---------------------------------------------------+
没有最好的代码，是因为我们总能把代码改得更好。
因此我们现在打算做一个小的性能改进，这次我们准备拿free_diskmem()函数下刀。
本质上说，这个改进的意义不大，这是因为free_diskmem()函数仅仅是在模块卸载时被调用，
而对这种执行次数即少又不在关键路径上的函数来说，最好是尽量让他简单以增加可靠性和可读性，
除非它的耗时已经慢到能让人有所感觉，否则0.01秒和0.00001秒是差不多的，毕竟在现实中尼奥不太可能用我们的程序。
但我们仍然打算继续这一改进，一是为了示范什么是没有意义的改进，二是为了通过这一改进示范使用radix_tree_gang_lookup()函数和page->index的技巧。
首先我们看看原先的free_diskmem()函数：
void free_diskmem(void)
{
int i;
struct page *page;
for (i = 0; i < (simp_blkdev_bytes + SIMP_BLKDEV_DATASEGSIZE - 1)
>> SIMP_BLKDEV_DATASEGSHIFT; i++) {
page = radix_tree_lookup(&simp_blkdev_data, i);
radix_tree_delete(&simp_blkdev_data, i);
/* free NULL is safe */
__free_pages(page, SIMP_BLKDEV_DATASEGORDER);
}
}
它遍历所有的内存块索引，在基树中找到这个内存块的page指针，然后释放内存，顺带着释放掉基数中的这个节点。
考虑到这个函数不仅会在模块卸载时被调用，也会在模块加载时、申请内存中途掉链子时用来擦屁股，因此也需要考虑内存没有完全申请的情况。
所幸的是这种情况下radix_tree_lookup()函数会返回NULL指针，而radix_tree_delete()和__free_pages()函数都能对NULL指针做出我们最期待的处理：就是什么也不做。
这段代码很小很直接，逻辑简单而清晰，性能也差不到哪里去，完全符合设计要求，
不幸的是我们还是打算做一些没必要的优化，借此还可以顺便读一读基树的内核代码。
首先看radix_tree_lookup()函数，它在基数中查找指定索引对应的指针，为了获得这一指针的值，基本上它需要把基树从上到下找一遍。
而对于free_diskmem()函数而言，我们仅仅是需要遍历基树中的所有节点，使用逐一查找的方法进行遍历未免代价太大了。
就像是我们要给在场的所有同学每人发一个糖果，只需要让他们排好队，每人领一个即可，而不需要按照名单找出每个人再发。
为了实现这一思想，我们跑到linux/lib/radix-tree.c中找函数，找啊找，找到了radix_tree_gang_lookup()函数。
radix_tree_gang_lookup()函数虽然不是我们理想中的遍历函数，但也有了八九不离十的功能。
就像在酒吧里找不到D Cup，带回去个C Cup也总比看A片强。
通过radix_tree_gang_lookup()函数，我们可以一次从基树中获取多个节点的信息：
unsigned int radix_tree_gang_lookup(struct radix_tree_root *root, void **results, unsigned long first_index, unsigned int max_items);
具体的参数嘛，RTFSC吧。
这是我们注意到使用这个函数时顾此失彼的一面，虽然我们获得了一组需要释放的指针，但却无法获得这些指针的索引。
而执行释放基树中节点的操作时却恰恰需要使用索引作参数。
然后就是一个技巧了，我们借用page结构的index成员来存储这一索引。
之所以可以这样用，是因为page结构的index成员在该页用作页高速缓存时存储相对文件起始处的以页大小为单位的偏移，
而我们所使用的页面不会被同时用作页高速缓存，因此这里可以借用page.index成员。
按照以上思路，我们写出了修改后的代码：
void free_diskmem(void)
{
unsigned long long next_seg;
struct page *seglist[64];
int listcnt;
int i;
next_seg = 0;
do {
listcnt = radix_tree_gang_lookup(&simp_blkdev_data,
(void **)seglist, next_seg, ARRAY_SIZE(seglist));
for (i = 0; i < listcnt; i++) {
next_seg = seglist[i]->index;
radix_tree_delete(&simp_blkdev_data, next_seg);
__free_pages(seglist[i], SIMP_BLKDEV_DATASEGORDER);
}
next_seg++;
} while (listcnt == ARRAY_SIZE(seglist));
}
当然，alloc_diskmem()函数中也需要加上page->index = i这一行，用于把基树的索引存入page.index，修改后的代码如下：
int alloc_diskmem(void)
{
int ret;
int i;
struct page *page;
INIT_RADIX_TREE(&simp_blkdev_data, GFP_KERNEL);
for (i = 0; i < (simp_blkdev_bytes + SIMP_BLKDEV_DATASEGSIZE - 1)
>> SIMP_BLKDEV_DATASEGSHIFT; i++) {
page = alloc_pages(GFP_KERNEL | __GFP_ZERO | __GFP_HIGHMEM,
SIMP_BLKDEV_DATASEGORDER);
if (!page) {
ret = -ENOMEM;
goto err_alloc;
}
page->index = i;
ret = radix_tree_insert(&simp_blkdev_data, i, page);
if (IS_ERR_VALUE(ret))
goto err_radix_tree_insert;
}
return 0;
err_radix_tree_insert:
__free_pages(page, SIMP_BLKDEV_DATASEGORDER);
err_alloc:
free_diskmem();
return ret;
}
现在试验一下修改后的代码，先看看能不能编译：
# make
make -C /lib/modules/2.6.18-53.el5/build SUBDIRS=/root/test/simp_blkdev/simp_blkdev_step13 modules
make[1]: Entering directory `/usr/src/kernels/2.6.18-53.el5-i686'
CC [M] /root/test/simp_blkdev/simp_blkdev_step13/simp_blkdev.o
Building modules, stage 2.
MODPOST
CC /root/test/simp_blkdev/simp_blkdev_step13/simp_blkdev.mod.o
LD [M] /root/test/simp_blkdev/simp_blkdev_step13/simp_blkdev.ko
make[1]: Leaving directory `/usr/src/kernels/2.6.18-53.el5-i686'
#
看看当前系统的内存情况：
# cat /proc/meminfo
HighTotal: 1146816 kB
HighFree: 339144 kB
LowTotal: 896356 kB
LowFree: 630920 kB
...
#
这里显示现在剩余339M高端内存和630M低端内存。
然后加载我们的模块，让它吃掉300M内存：
# insmod simp_blkdev.ko size=300M
# cat /proc/meminfo
HighTotal: 1146816 kB
HighFree: 137964 kB
LowTotal: 896356 kB
LowFree: 523900 kB
...
#
正如我们的预期，剩余内存减少300M左右。
然后看看卸载模块后的内存情况：
# rmmod simp_blkdev
# cat /proc/meminfo
HighTotal: 1146816 kB
HighFree: 338028 kB
LowTotal: 896356 kB
LowFree: 631044 kB
...
#
我们发现剩余内存增加了300M，这意味着模块已经把吃掉的内存吐回来了，
从而可以推断出我们修改过的free_diskmem()函数基本上是能够工作的。
本章的改动不大，就算是暂作休整，以留住忍耐至今忍无可忍认为无需再忍而开始打包收拾行李准备溜之大吉的读者们。
不过下一章中倒是预备了一个做起来让人比较有成就感的功能。
<未完，待续>
第14章
+---------------------------------------------------+
| 写一个块设备驱动 |
+---------------------------------------------------+
| 作者：赵磊 |
| email: zhaoleidd@hotmail.com |
+---------------------------------------------------+
| 文章版权归原作者所有。 |
| 大家可以自由转载这篇文章，但原版权信息必须保留。 |
| 如需用于商业用途，请务必与原作者联系，若因未取得 |
| 授权而收起的版权争议，由侵权者自行负责。 |
+---------------------------------------------------+
在本章中我们要做一个比较大的改进，就是实现内存的推迟分配。
这意味着我们并不是在驱动程序加载时就分配用于容纳数据的全部内存，
而是推迟到真正需要用到某块内存时再进行分配。
详细来说，我们将在块设备的某个区域上发生第一次写请求时分配用于容纳被写入数据的内存，
如果读者在之前章节的熏陶下养成了细致的作风和勤于思考的习惯，
应该能发现这里提到的分配内存的时机是第一次写，而不是第一次读写。
现在可能有些读者已经悟出了这样做的道理，让我们无视他们，依然解释一下这样做的目的。
对块设备而言，只要保证读出的数据是最近一次写进的即可。
如果在读数据之前从来没有往块设备的同一块区域中写入数据，那么这时返回任何随机数据都是正确的。
这意味着对于第一次读，我们完全可以返回任意的数据给用户，这时并不需要分配某段内存来存储它。
对真实的物理设备而言，就像我们买回的新硬盘，出厂时盘片中的数据内容是什么都无所谓。
在具体的实现中，我们可以不对用以接收被读出数据的内存进行任何填充，直接告诉上层“已经读好了”，
这样做无疑会更加快速，但这会造成2个问题：
1：这块内存原先的内容最终将被传送到用户程序中，这将造成数据安全问题
2：违背了真实设备的一个潜特性，就是即使这个设备没有写入任何内容，对同一区域的多次读操作返回的内容相同。
因此，我们将向接收数据的内存中写些什么，最简单的就是用全0填充了。
实现这一功能的优点在于，块设备不需要在一开始加载时就占用全部的内存，这优化了系统资源的使用率。
让我们假设块设备自始至终没有被全部填满时，通过本章的功能，将占用更少的内存。
另外，我们甚至可以创建容量远远大于机器物理内存的块设备，只要在随后的使用中不往这个块设备中写入过多的内容即可。
在linux中，类似的思想被广泛应用。
比如对进程的内存区而言，并不是一开始就为这段内存区申请和映射全部需要的物理内存，
又如在不少文件系统中，也不会给没有写入内容的文件部分分配磁盘的。
现在我们就实现这一功能。
分析代码，我们发现不太容易找到往什么地方加代码。
往往在这种情况下，不如首先看看可以剥掉哪部分不需要的代码，
正如初次跟一个mm时，如果两个人都有些害羞，不知道从哪开始、或者正在期待对方打开局面时，
不如先脱下该脱的东西，然后的事情基本上就比较自然了。
现在的代码中，明显可以砍掉的是在驱动程序加载时用于申请容纳数据的内存的代码，
也就是alloc_diskmem()函数，把它砍了，没错，是全砍了。
还有调用它的代码，在simp_blkdev_init()函数里面的这几行：
ret = alloc_diskmem();
if (IS_ERR_VALUE(ret))
goto err_alloc_diskmem;
是的，也砍了。
还没完，既然这个函数的调用都没了，那么调用这个函数失败时的出错处理也没用了，也就是：
err_alloc_diskmem:
put_disk(simp_blkdev_disk);
这两句，不用犹豫了，砍掉。
经过刚才的大刀阔斧后，我们发现......刚才由于砍上瘾了，不小心多砍了一条语句，就是对基树的初始化语句：
INIT_RADIX_TREE(&simp_blkdev_data, GFP_KERNEL);
原来它是在alloc_diskmem()函数里面的，现在alloc_diskmem()函数不在了，我们索性把它放到初始化模块的simp_blkdev_init()函数中，
放到刚才原来调用alloc_diskmem()函数的位置就行了。
(注：
其实这里不添加INIT_RADIX_TREE()宏也行，直接在定义基树结构时顺便初始化掉就行了，也就是把
static struct radix_tree_root simp_blkdev_data;
改成
static struct radix_tree_root simp_blkdev_data = RADIX_TREE_INIT(GFP_KERNEL);
就行了，或者改成让人更加撞墙的形式：
static RADIX_TREE(simp_blkdev_data, GFP_KERNEL);
也可以，但我们这里的代码中，依然沿用原先的方式。
)
这样一来，simp_blkdev_init()函数变成了这个样子：
static int __init simp_blkdev_init(void)
{
int ret;
ret = getparam();
if (IS_ERR_VALUE(ret))
goto err_getparam;
simp_blkdev_queue = blk_alloc_queue(GFP_KERNEL);
if (!simp_blkdev_queue) {
ret = -ENOMEM;
goto err_alloc_queue;
}
blk_queue_make_request(simp_blkdev_queue, simp_blkdev_make_request);
simp_blkdev_disk = alloc_disk(SIMP_BLKDEV_MAXPARTITIONS);
if (!simp_blkdev_disk) {
ret = -ENOMEM;
goto err_alloc_disk;
}
INIT_RADIX_TREE(&simp_blkdev_data, GFP_KERNEL);
strcpy(simp_blkdev_disk->disk_name, SIMP_BLKDEV_DISKNAME);
simp_blkdev_disk->major = SIMP_BLKDEV_DEVICEMAJOR;
simp_blkdev_disk->first_minor = 0;
simp_blkdev_disk->fops = &simp_blkdev_fops;
simp_blkdev_disk->queue = simp_blkdev_queue;
set_capacity(simp_blkdev_disk,
simp_blkdev_bytes >> SIMP_BLKDEV_SECTORSHIFT);
add_disk(simp_blkdev_disk);
return 0;
err_alloc_disk:
blk_cleanup_queue(simp_blkdev_queue);
err_alloc_queue:
err_getparam:
return ret;
}
淋漓尽致地大砍一番之后，我们发现下一步的工作清晰多了。
现在在模块加载时，已经不会申请所需的内存，而我们需要做的就是，
在处理块设备读写操作时，添加不存在相应内存时的处理代码。
在程序中，查找基数中的一个内存块是在simp_blkdev_trans()函数内完成的，目前的处理是：
this_first_page = radix_tree_lookup(&simp_blkdev_data,
(dsk_offset + done_cnt) >> SIMP_BLKDEV_DATASEGSHIFT);
if (!this_first_page) {
printk(KERN_ERR SIMP_BLKDEV_DISKNAME
": search memory failed: %llu\n",
(dsk_offset + done_cnt)
>> SIMP_BLKDEV_DATASEGSHIFT);
return -ENOENT;
}
也就是找不到内存块时直接看作错误。
在以前这是正确的，因为所有的内存块都在初始化驱动程序时申请了，因此除非电脑的脑子进水了，
运行错了指令，或者人脑的脑子进水了，编错了代码，否则不会发生这种情况。
但现在情况不同了，这时找不到内存块是正常的，这意味着该位置的数据从未被写入过，
因此我们需要在这里做出合理的动作。
也就是在本章开始时所说的，对于读处理返回全0，对于写处理给块设备的这段空间申请内存，并写入数据。
因此我们把上段代码改成了这个样子：
this_first_page = radix_tree_lookup(&simp_blkdev_data,
(dsk_offset + done_cnt) >> SIMP_BLKDEV_DATASEGSHIFT);
if (!this_first_page) {
if (!dir) {
memset(buf + done_cnt, 0, this_cnt);
goto trans_done;
}
/* prepare new memory segment for write */
this_first_page = alloc_pages(
GFP_KERNEL | __GFP_ZERO | __GFP_HIGHMEM,
SIMP_BLKDEV_DATASEGORDER);
if (!this_first_page) {
printk(KERN_ERR SIMP_BLKDEV_DISKNAME
": allocate page failed\n");
return -ENOMEM;
}
this_first_page->index = (dsk_offset + done_cnt)
>> SIMP_BLKDEV_DATASEGSHIFT;
if (IS_ERR_VALUE(radix_tree_insert(&simp_blkdev_data,
this_first_page->index, this_first_page))) {
printk(KERN_ERR SIMP_BLKDEV_DISKNAME
": insert page to radix_tree failed"
" seg=%lu\n", this_first_page->index);
__free_pages(this_first_page,
SIMP_BLKDEV_DATASEGORDER);
return -EIO;
}
}
对这段代码的流程几乎不要解释了，因为代码本身就是最好的说明。
唯一要提一下的就是goto trans_done这句话，因为前一条语句实质上已经完成了数据读取，
因此需要直接跳转到该段数据处理完成的位置，也就是函数中的done_cnt += this_cnt语句之前。
说到这里猴急的读者可能已经在done_cnt += this_cnt语句之前添加
trans_done:
这一行了，不错，正是要加这一行。
改过的simp_blkdev_trans()函数变成了这个样子：
static int simp_blkdev_trans(unsigned long long dsk_offset, void *buf,
unsigned int len, int dir)
{
unsigned int done_cnt;
struct page *this_first_page;
unsigned int this_off;
unsigned int this_cnt;
done_cnt = 0;
while (done_cnt < len) {
/* iterate each data segment */
this_off = (dsk_offset + done_cnt) & ~SIMP_BLKDEV_DATASEGMASK;
this_cnt = min(len - done_cnt,
(unsigned int)SIMP_BLKDEV_DATASEGSIZE - this_off);
this_first_page = radix_tree_lookup(&simp_blkdev_data,
(dsk_offset + done_cnt) >> SIMP_BLKDEV_DATASEGSHIFT);
if (!this_first_page) {
if (!dir) {
memset(buf + done_cnt, 0, this_cnt);
goto trans_done;
}
/* prepare new memory segment for write */
this_first_page = alloc_pages(
GFP_KERNEL | __GFP_ZERO | __GFP_HIGHMEM,
SIMP_BLKDEV_DATASEGORDER);
if (!this_first_page) {
printk(KERN_ERR SIMP_BLKDEV_DISKNAME
": allocate page failed\n");
return -ENOMEM;
}
this_first_page->index = (dsk_offset + done_cnt)
>> SIMP_BLKDEV_DATASEGSHIFT;
if (IS_ERR_VALUE(radix_tree_insert(&simp_blkdev_data,
this_first_page->index, this_first_page))) {
printk(KERN_ERR SIMP_BLKDEV_DISKNAME
": insert page to radix_tree failed"
" seg=%lu\n", this_first_page->index);
__free_pages(this_first_page,
SIMP_BLKDEV_DATASEGORDER);
return -EIO;
}
}
if (IS_ERR_VALUE(simp_blkdev_trans_oneseg(this_first_page,
this_off, buf + done_cnt, this_cnt, dir)))
return -EIO;
trans_done:
done_cnt += this_cnt;
}
return 0;
}
代码就这样被莫名其妙地改完了，感觉这次的改动比预想的少，并且也比较集中，
这其实还是托了前些章的福，正是在此之前对程序结构的规划调整，
在增加可读性的同时，也给随后的维护带来方便。
处于良好维护下的程序代码结构应该越维护越让人赏心悦目，而不是越维护越混乱不堪。
现在我们来试验一下这次修改的效果：
先编译：
# make
make -C /lib/modules/2.6.18-53.el5/build SUBDIRS=/root/test/simp_blkdev/simp_blkdev_step14 modules
make[1]: Entering directory `/usr/src/kernels/2.6.18-53.el5-i686'
CC [M] /root/test/simp_blkdev/simp_blkdev_step14/simp_blkdev.o
Building modules, stage 2.
MODPOST
CC /root/test/simp_blkdev/simp_blkdev_step14/simp_blkdev.mod.o
LD [M] /root/test/simp_blkdev/simp_blkdev_step14/simp_blkdev.ko
make[1]: Leaving directory `/usr/src/kernels/2.6.18-53.el5-i686'
#
没发现问题。
然后看看目前的内存状况：
# cat /proc/meminfo
...
HighTotal: 1146816 kB
HighFree: 87920 kB
LowTotal: 896356 kB
LowFree: 791920 kB
...
#
可以看出高端和低端内存分别剩余87M和791M。
然后指定size=50M加载模块后看看内存变化：
# insmod simp_blkdev.ko size=50M
# cat /proc/meminfo
...
HighTotal: 1146816 kB
HighFree: 86804 kB
LowTotal: 896356 kB
LowFree: 791912 kB
...
#
在这里我们发现剩余内存的变化不大，
这也证明了这次修改的效果，因为加载模块时不会申请用于存储数据的全部内存。
而在原先的代码中，这一步骤将使机器减少大约50M的剩余空间。
然后我们来验证读取块设备时也不会导致分配内存：
# dd if=/dev/simp_blkdev of=/dev/null
102400+0 records in
102400+0 records out
52428800 bytes (52 MB) copied, 0.376118 seconds, 139 MB/s
# cat /proc/meminfo
...
HighTotal: 1146816 kB
HighFree: 85440 kB
LowTotal: 896356 kB
LowFree: 791888 kB
...
#
剩余内存几乎没有变化，这证明了我们的设想。
然后是写设备的情况：
# dd if=/dev/zero of=/dev/simp_blkdev
dd: writing to `/dev/simp_blkdev': No space left on device
102401+0 records in
102400+0 records out
52428800 bytes (52 MB) copied, 0.542117 seconds, 96.7 MB/s
# cat /proc/meminfo
...
HighTotal: 1146816 kB
HighFree: 34116 kB
LowTotal: 896356 kB
LowFree: 791516 kB
...
#
这时剩余内存终于减少了大约50M，
这意味着驱动程序申请了大约50M的内存用于存储写入的数据。
如果向已写入的位置再次写入数据，理论上不应该造成再一次的分配，
让我们试试：
# dd if=/dev/zero of=/dev/simp_blkdev
dd: writing to `/dev/simp_blkdev': No space left on device
102401+0 records in
102400+0 records out
52428800 bytes (52 MB) copied, 0.644972 seconds, 81.3 MB/s
# cat /proc/meminfo
...
HighTotal: 1146816 kB
HighFree: 33620 kB
LowTotal: 896356 kB
LowFree: 791516 kB
...
#
结果与预想一致。
现在卸载模块：
# rmmod simp_blkdev
# cat /proc/meminfo
...
HighTotal: 1146816 kB
HighFree: 84572 kB
LowTotal: 896356 kB
LowFree: 791640 kB
...
#
我们发现被驱动程序使用的内存被释放回来了。
如果以上的实验没有让读者过瘾的话，我们来继续一个过分一些的，
也就是创建空间远远大于机器物理内存的块设备。
首先我们看看目前的系统内存状况：
# cat /proc/meminfo
...
HighTotal: 1146816 kB
HighFree: 77688 kB
LowTotal: 896356 kB
LowFree: 783296 kB
...
#
机器的总内存是2G，目前剩余的高、低端内存加起来是860M左右。
然后我们加载模块，注意一下size参数的值：
# insmod simp_blkdev.ko size=10000G
#
命令成功返回，而如果换作原先的代码，
命令出错返回......是不太可能的，
最可能的大概是内核直接panic。
这是因为申请光全部内存的操作将导致申请出错时运行的用于释放内存的代码所需要的内存都无法满足。
无论我们设置多大的块设备容量，模块加载后只要不执行写操作，
驱动程序都不会申请存储数据的内存。而这个测试：
# cat /proc/meminfo
...
HighTotal: 1146816 kB
HighFree: 75208 kB
LowTotal: 896356 kB
LowFree: 783132 kB
...
#
也证明了这一点。
现在我们看看这时的块设备情况：
# fdisk -l /dev/simp_blkdev
Disk /dev/simp_blkdev: 10737.4 GB, 10737418240000 bytes
255 heads, 63 sectors/track, 1305416 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk /dev/simp_blkdev doesn't contain a valid partition table
#
果然是10000G，这可以通过换算10737418240000 bytes得到。
而fdisk显示10737.4 GB是因为它是按照1k=1000字节、1M=1000K、1G=1000M来算的，
这种流氓的算法给硬盘厂商的缺斤少两行为提供了极好的借口。
这里省略fdisk、mkfs、mount、cp等操作，
直接用dd往这个"10000G磁盘"中写入50M的数据：
# dd if=/dev/zero of=/dev/simp_blkdev bs=1M count=50
50+0 records in
50+0 records out
52428800 bytes (52 MB) copied, 0.324054 seconds, 162 MB/s
# cat /proc/meminfo
...
HighTotal: 1146816 kB
HighFree: 23512 kB
LowTotal: 896356 kB
LowFree: 782884 kB
...
#
现在的内存情况证明我们的"10000G磁盘"为这些数据申请了50M的内存。
实验差不多了，我们卸载模块：
# rmmod simp_blkdev.
#
做完以上的实验，读者可能会有一个疑问，如果我们真的向那个"10000G磁盘"中写入了10000G的数据怎么样呢？
回答可能不太如人意，就是系统很可能会panic。
因为这个操作将迫使驱动程序吃掉全部可能获得的物理内存，并且在吃光最后那么一丁点内存之前不会发生错误，
这也意味着走到出错处理这一步的时候，系统已经几乎无可救药了。其实在此之前系统就会一次进行：
释放缓存、试图把所有的用户进程的内存换出、杀死全部能够杀死的进程等操作。
而我们的驱动程序由于被看作是内核的一部分，却不会被停止，而是在继续不停的吃掉通过上述方式释放出的可怜的内存。
试想，一个已经走到这一步的系统还有什么继续运行的可能呢？
因此，我们的程序确实需要改善以解决这个问题，因为世界上总是有一些疯狂的人在想各种办法虐待电脑。
但我们并不打算在本教程中解决它，因为这个教程中的每一章都企图为读者说明一类知识或一种方法，
而不是仅仅为了这个示例性质的程序的功能本身。
所以这一项改善就当作是留给读者的练习了。
本章通过改善块设备驱动程序实现了内存的滞后申请，
其目的在于介绍这种方法，以使它在其他的相似程序中也得以实现。
不过，这并不意味着作者希望读者把这种方法过分引用，
比如引用成平时不学习，考试前临时抱佛脚。
<未完，待续>
第13章
+---------------------------------------------------+
| 写一个块设备驱动 |
+---------------------------------------------------+
| 作者：赵磊 |
| email: zhaoleidd@hotmail.com |
+---------------------------------------------------+
| 文章版权归原作者所有。 |
| 大家可以自由转载这篇文章，但原版权信息必须保留。 |
| 如需用于商业用途，请务必与原作者联系，若因未取得 |
| 授权而收起的版权争议，由侵权者自行负责。 |
+---------------------------------------------------+
没有最好的代码，是因为我们总能把代码改得更好。
因此我们现在打算做一个小的性能改进，这次我们准备拿free_diskmem()函数下刀。
本质上说，这个改进的意义不大，这是因为free_diskmem()函数仅仅是在模块卸载时被调用，
而对这种执行次数即少又不在关键路径上的函数来说，最好是尽量让他简单以增加可靠性和可读性，
除非它的耗时已经慢到能让人有所感觉，否则0.01秒和0.00001秒是差不多的，毕竟在现实中尼奥不太可能用我们的程序。
但我们仍然打算继续这一改进，一是为了示范什么是没有意义的改进，二是为了通过这一改进示范使用radix_tree_gang_lookup()函数和page->index的技巧。
首先我们看看原先的free_diskmem()函数：
void free_diskmem(void)
{
int i;
struct page *page;
for (i = 0; i < (simp_blkdev_bytes + SIMP_BLKDEV_DATASEGSIZE - 1)
>> SIMP_BLKDEV_DATASEGSHIFT; i++) {
page = radix_tree_lookup(&simp_blkdev_data, i);
radix_tree_delete(&simp_blkdev_data, i);
/* free NULL is safe */
__free_pages(page, SIMP_BLKDEV_DATASEGORDER);
}
}
它遍历所有的内存块索引，在基树中找到这个内存块的page指针，然后释放内存，顺带着释放掉基数中的这个节点。
考虑到这个函数不仅会在模块卸载时被调用，也会在模块加载时、申请内存中途掉链子时用来擦屁股，因此也需要考虑内存没有完全申请的情况。
所幸的是这种情况下radix_tree_lookup()函数会返回NULL指针，而radix_tree_delete()和__free_pages()函数都能对NULL指针做出我们最期待的处理：就是什么也不做。
这段代码很小很直接，逻辑简单而清晰，性能也差不到哪里去，完全符合设计要求，
不幸的是我们还是打算做一些没必要的优化，借此还可以顺便读一读基树的内核代码。
首先看radix_tree_lookup()函数，它在基数中查找指定索引对应的指针，为了获得这一指针的值，基本上它需要把基树从上到下找一遍。
而对于free_diskmem()函数而言，我们仅仅是需要遍历基树中的所有节点，使用逐一查找的方法进行遍历未免代价太大了。
就像是我们要给在场的所有同学每人发一个糖果，只需要让他们排好队，每人领一个即可，而不需要按照名单找出每个人再发。
为了实现这一思想，我们跑到linux/lib/radix-tree.c中找函数，找啊找，找到了radix_tree_gang_lookup()函数。
radix_tree_gang_lookup()函数虽然不是我们理想中的遍历函数，但也有了八九不离十的功能。
就像在酒吧里找不到D Cup，带回去个C Cup也总比看A片强。
通过radix_tree_gang_lookup()函数，我们可以一次从基树中获取多个节点的信息：
unsigned int radix_tree_gang_lookup(struct radix_tree_root *root, void **results, unsigned long first_index, unsigned int max_items);
具体的参数嘛，RTFSC吧。
这是我们注意到使用这个函数时顾此失彼的一面，虽然我们获得了一组需要释放的指针，但却无法获得这些指针的索引。
而执行释放基树中节点的操作时却恰恰需要使用索引作参数。
然后就是一个技巧了，我们借用page结构的index成员来存储这一索引。
之所以可以这样用，是因为page结构的index成员在该页用作页高速缓存时存储相对文件起始处的以页大小为单位的偏移，
而我们所使用的页面不会被同时用作页高速缓存，因此这里可以借用page.index成员。
按照以上思路，我们写出了修改后的代码：
void free_diskmem(void)
{
unsigned long long next_seg;
struct page *seglist[64];
int listcnt;
int i;
next_seg = 0;
do {
listcnt = radix_tree_gang_lookup(&simp_blkdev_data,
(void **)seglist, next_seg, ARRAY_SIZE(seglist));
for (i = 0; i < listcnt; i++) {
next_seg = seglist[i]->index;
radix_tree_delete(&simp_blkdev_data, next_seg);
__free_pages(seglist[i], SIMP_BLKDEV_DATASEGORDER);
}
next_seg++;
} while (listcnt == ARRAY_SIZE(seglist));
}
当然，alloc_diskmem()函数中也需要加上page->index = i这一行，用于把基树的索引存入page.index，修改后的代码如下：
int alloc_diskmem(void)
{
int ret;
int i;
struct page *page;
INIT_RADIX_TREE(&simp_blkdev_data, GFP_KERNEL);
for (i = 0; i < (simp_blkdev_bytes + SIMP_BLKDEV_DATASEGSIZE - 1)
>> SIMP_BLKDEV_DATASEGSHIFT; i++) {
page = alloc_pages(GFP_KERNEL | __GFP_ZERO | __GFP_HIGHMEM,
SIMP_BLKDEV_DATASEGORDER);
if (!page) {
ret = -ENOMEM;
goto err_alloc;
}
page->index = i;
ret = radix_tree_insert(&simp_blkdev_data, i, page);
if (IS_ERR_VALUE(ret))
goto err_radix_tree_insert;
}
return 0;
err_radix_tree_insert:
__free_pages(page, SIMP_BLKDEV_DATASEGORDER);
err_alloc:
free_diskmem();
return ret;
}
现在试验一下修改后的代码，先看看能不能编译：
# make
make -C /lib/modules/2.6.18-53.el5/build SUBDIRS=/root/test/simp_blkdev/simp_blkdev_step13 modules
make[1]: Entering directory `/usr/src/kernels/2.6.18-53.el5-i686'
CC [M] /root/test/simp_blkdev/simp_blkdev_step13/simp_blkdev.o
Building modules, stage 2.
MODPOST
CC /root/test/simp_blkdev/simp_blkdev_step13/simp_blkdev.mod.o
LD [M] /root/test/simp_blkdev/simp_blkdev_step13/simp_blkdev.ko
make[1]: Leaving directory `/usr/src/kernels/2.6.18-53.el5-i686'
#
看看当前系统的内存情况：
# cat /proc/meminfo
HighTotal: 1146816 kB
HighFree: 339144 kB
LowTotal: 896356 kB
LowFree: 630920 kB
...
#
这里显示现在剩余339M高端内存和630M低端内存。
然后加载我们的模块，让它吃掉300M内存：
# insmod simp_blkdev.ko size=300M
# cat /proc/meminfo
HighTotal: 1146816 kB
HighFree: 137964 kB
LowTotal: 896356 kB
LowFree: 523900 kB
...
#
正如我们的预期，剩余内存减少300M左右。
然后看看卸载模块后的内存情况：
# rmmod simp_blkdev
# cat /proc/meminfo
HighTotal: 1146816 kB
HighFree: 338028 kB
LowTotal: 896356 kB
LowFree: 631044 kB
...
#
我们发现剩余内存增加了300M，这意味着模块已经把吃掉的内存吐回来了，
从而可以推断出我们修改过的free_diskmem()函数基本上是能够工作的。
本章的改动不大，就算是暂作休整，以留住忍耐至今忍无可忍认为无需再忍而开始打包收拾行李准备溜之大吉的读者们。
不过下一章中倒是预备了一个做起来让人比较有成就感的功能。
<未完，待续>
第14章
+---------------------------------------------------+
| 写一个块设备驱动 |
+---------------------------------------------------+
| 作者：赵磊 |
| email: zhaoleidd@hotmail.com |
+---------------------------------------------------+
| 文章版权归原作者所有。 |
| 大家可以自由转载这篇文章，但原版权信息必须保留。 |
| 如需用于商业用途，请务必与原作者联系，若因未取得 |
| 授权而收起的版权争议，由侵权者自行负责。 |
+---------------------------------------------------+
在本章中我们要做一个比较大的改进，就是实现内存的推迟分配。
这意味着我们并不是在驱动程序加载时就分配用于容纳数据的全部内存，
而是推迟到真正需要用到某块内存时再进行分配。
详细来说，我们将在块设备的某个区域上发生第一次写请求时分配用于容纳被写入数据的内存，
如果读者在之前章节的熏陶下养成了细致的作风和勤于思考的习惯，
应该能发现这里提到的分配内存的时机是第一次写，而不是第一次读写。
现在可能有些读者已经悟出了这样做的道理，让我们无视他们，依然解释一下这样做的目的。
对块设备而言，只要保证读出的数据是最近一次写进的即可。
如果在读数据之前从来没有往块设备的同一块区域中写入数据，那么这时返回任何随机数据都是正确的。
这意味着对于第一次读，我们完全可以返回任意的数据给用户，这时并不需要分配某段内存来存储它。
对真实的物理设备而言，就像我们买回的新硬盘，出厂时盘片中的数据内容是什么都无所谓。
在具体的实现中，我们可以不对用以接收被读出数据的内存进行任何填充，直接告诉上层“已经读好了”，
这样做无疑会更加快速，但这会造成2个问题：
1：这块内存原先的内容最终将被传送到用户程序中，这将造成数据安全问题
2：违背了真实设备的一个潜特性，就是即使这个设备没有写入任何内容，对同一区域的多次读操作返回的内容相同。
因此，我们将向接收数据的内存中写些什么，最简单的就是用全0填充了。
实现这一功能的优点在于，块设备不需要在一开始加载时就占用全部的内存，这优化了系统资源的使用率。
让我们假设块设备自始至终没有被全部填满时，通过本章的功能，将占用更少的内存。
另外，我们甚至可以创建容量远远大于机器物理内存的块设备，只要在随后的使用中不往这个块设备中写入过多的内容即可。
在linux中，类似的思想被广泛应用。
比如对进程的内存区而言，并不是一开始就为这段内存区申请和映射全部需要的物理内存，
又如在不少文件系统中，也不会给没有写入内容的文件部分分配磁盘的。
现在我们就实现这一功能。
分析代码，我们发现不太容易找到往什么地方加代码。
往往在这种情况下，不如首先看看可以剥掉哪部分不需要的代码，
正如初次跟一个mm时，如果两个人都有些害羞，不知道从哪开始、或者正在期待对方打开局面时，
不如先脱下该脱的东西，然后的事情基本上就比较自然了。
现在的代码中，明显可以砍掉的是在驱动程序加载时用于申请容纳数据的内存的代码，
也就是alloc_diskmem()函数，把它砍了，没错，是全砍了。
还有调用它的代码，在simp_blkdev_init()函数里面的这几行：
ret = alloc_diskmem();
if (IS_ERR_VALUE(ret))
goto err_alloc_diskmem;
是的，也砍了。
还没完，既然这个函数的调用都没了，那么调用这个函数失败时的出错处理也没用了，也就是：
err_alloc_diskmem:
put_disk(simp_blkdev_disk);
这两句，不用犹豫了，砍掉。
经过刚才的大刀阔斧后，我们发现......刚才由于砍上瘾了，不小心多砍了一条语句，就是对基树的初始化语句：
INIT_RADIX_TREE(&simp_blkdev_data, GFP_KERNEL);
原来它是在alloc_diskmem()函数里面的，现在alloc_diskmem()函数不在了，我们索性把它放到初始化模块的simp_blkdev_init()函数中，
放到刚才原来调用alloc_diskmem()函数的位置就行了。
(注：
其实这里不添加INIT_RADIX_TREE()宏也行，直接在定义基树结构时顺便初始化掉就行了，也就是把
static struct radix_tree_root simp_blkdev_data;
改成
static struct radix_tree_root simp_blkdev_data = RADIX_TREE_INIT(GFP_KERNEL);
就行了，或者改成让人更加撞墙的形式：
static RADIX_TREE(simp_blkdev_data, GFP_KERNEL);
也可以，但我们这里的代码中，依然沿用原先的方式。
)
这样一来，simp_blkdev_init()函数变成了这个样子：
static int __init simp_blkdev_init(void)
{
int ret;
ret = getparam();
if (IS_ERR_VALUE(ret))
goto err_getparam;
simp_blkdev_queue = blk_alloc_queue(GFP_KERNEL);
if (!simp_blkdev_queue) {
ret = -ENOMEM;
goto err_alloc_queue;
}
blk_queue_make_request(simp_blkdev_queue, simp_blkdev_make_request);
simp_blkdev_disk = alloc_disk(SIMP_BLKDEV_MAXPARTITIONS);
if (!simp_blkdev_disk) {
ret = -ENOMEM;
goto err_alloc_disk;
}
INIT_RADIX_TREE(&simp_blkdev_data, GFP_KERNEL);
strcpy(simp_blkdev_disk->disk_name, SIMP_BLKDEV_DISKNAME);
simp_blkdev_disk->major = SIMP_BLKDEV_DEVICEMAJOR;
simp_blkdev_disk->first_minor = 0;
simp_blkdev_disk->fops = &simp_blkdev_fops;
simp_blkdev_disk->queue = simp_blkdev_queue;
set_capacity(simp_blkdev_disk,
simp_blkdev_bytes >> SIMP_BLKDEV_SECTORSHIFT);
add_disk(simp_blkdev_disk);
return 0;
err_alloc_disk:
blk_cleanup_queue(simp_blkdev_queue);
err_alloc_queue:
err_getparam:
return ret;
}
淋漓尽致地大砍一番之后，我们发现下一步的工作清晰多了。
现在在模块加载时，已经不会申请所需的内存，而我们需要做的就是，
在处理块设备读写操作时，添加不存在相应内存时的处理代码。
在程序中，查找基数中的一个内存块是在simp_blkdev_trans()函数内完成的，目前的处理是：
this_first_page = radix_tree_lookup(&simp_blkdev_data,
(dsk_offset + done_cnt) >> SIMP_BLKDEV_DATASEGSHIFT);
if (!this_first_page) {
printk(KERN_ERR SIMP_BLKDEV_DISKNAME
": search memory failed: %llu\n",
(dsk_offset + done_cnt)
>> SIMP_BLKDEV_DATASEGSHIFT);
return -ENOENT;
}
也就是找不到内存块时直接看作错误。
在以前这是正确的，因为所有的内存块都在初始化驱动程序时申请了，因此除非电脑的脑子进水了，
运行错了指令，或者人脑的脑子进水了，编错了代码，否则不会发生这种情况。
但现在情况不同了，这时找不到内存块是正常的，这意味着该位置的数据从未被写入过，
因此我们需要在这里做出合理的动作。
也就是在本章开始时所说的，对于读处理返回全0，对于写处理给块设备的这段空间申请内存，并写入数据。
因此我们把上段代码改成了这个样子：
this_first_page = radix_tree_lookup(&simp_blkdev_data,
(dsk_offset + done_cnt) >> SIMP_BLKDEV_DATASEGSHIFT);
if (!this_first_page) {
if (!dir) {
memset(buf + done_cnt, 0, this_cnt);
goto trans_done;
}
/* prepare new memory segment for write */
this_first_page = alloc_pages(
GFP_KERNEL | __GFP_ZERO | __GFP_HIGHMEM,
SIMP_BLKDEV_DATASEGORDER);
if (!this_first_page) {
printk(KERN_ERR SIMP_BLKDEV_DISKNAME
": allocate page failed\n");
return -ENOMEM;
}
this_first_page->index = (dsk_offset + done_cnt)
>> SIMP_BLKDEV_DATASEGSHIFT;
if (IS_ERR_VALUE(radix_tree_insert(&simp_blkdev_data,
this_first_page->index, this_first_page))) {
printk(KERN_ERR SIMP_BLKDEV_DISKNAME
": insert page to radix_tree failed"
" seg=%lu\n", this_first_page->index);
__free_pages(this_first_page,
SIMP_BLKDEV_DATASEGORDER);
return -EIO;
}
}
对这段代码的流程几乎不要解释了，因为代码本身就是最好的说明。
唯一要提一下的就是goto trans_done这句话，因为前一条语句实质上已经完成了数据读取，
因此需要直接跳转到该段数据处理完成的位置，也就是函数中的done_cnt += this_cnt语句之前。
说到这里猴急的读者可能已经在done_cnt += this_cnt语句之前添加
trans_done:
这一行了，不错，正是要加这一行。
改过的simp_blkdev_trans()函数变成了这个样子：
static int simp_blkdev_trans(unsigned long long dsk_offset, void *buf,
unsigned int len, int dir)
{
unsigned int done_cnt;
struct page *this_first_page;
unsigned int this_off;
unsigned int this_cnt;
done_cnt = 0;
while (done_cnt < len) {
/* iterate each data segment */
this_off = (dsk_offset + done_cnt) & ~SIMP_BLKDEV_DATASEGMASK;
this_cnt = min(len - done_cnt,
(unsigned int)SIMP_BLKDEV_DATASEGSIZE - this_off);
this_first_page = radix_tree_lookup(&simp_blkdev_data,
(dsk_offset + done_cnt) >> SIMP_BLKDEV_DATASEGSHIFT);
if (!this_first_page) {
if (!dir) {
memset(buf + done_cnt, 0, this_cnt);
goto trans_done;
}
/* prepare new memory segment for write */
this_first_page = alloc_pages(
GFP_KERNEL | __GFP_ZERO | __GFP_HIGHMEM,
SIMP_BLKDEV_DATASEGORDER);
if (!this_first_page) {
printk(KERN_ERR SIMP_BLKDEV_DISKNAME
": allocate page failed\n");
return -ENOMEM;
}
this_first_page->index = (dsk_offset + done_cnt)
>> SIMP_BLKDEV_DATASEGSHIFT;
if (IS_ERR_VALUE(radix_tree_insert(&simp_blkdev_data,
this_first_page->index, this_first_page))) {
printk(KERN_ERR SIMP_BLKDEV_DISKNAME
": insert page to radix_tree failed"
" seg=%lu\n", this_first_page->index);
__free_pages(this_first_page,
SIMP_BLKDEV_DATASEGORDER);
return -EIO;
}
}
if (IS_ERR_VALUE(simp_blkdev_trans_oneseg(this_first_page,
this_off, buf + done_cnt, this_cnt, dir)))
return -EIO;
trans_done:
done_cnt += this_cnt;
}
return 0;
}
代码就这样被莫名其妙地改完了，感觉这次的改动比预想的少，并且也比较集中，
这其实还是托了前些章的福，正是在此之前对程序结构的规划调整，
在增加可读性的同时，也给随后的维护带来方便。
处于良好维护下的程序代码结构应该越维护越让人赏心悦目，而不是越维护越混乱不堪。
现在我们来试验一下这次修改的效果：
先编译：
# make
make -C /lib/modules/2.6.18-53.el5/build SUBDIRS=/root/test/simp_blkdev/simp_blkdev_step14 modules
make[1]: Entering directory `/usr/src/kernels/2.6.18-53.el5-i686'
CC [M] /root/test/simp_blkdev/simp_blkdev_step14/simp_blkdev.o
Building modules, stage 2.
MODPOST
CC /root/test/simp_blkdev/simp_blkdev_step14/simp_blkdev.mod.o
LD [M] /root/test/simp_blkdev/simp_blkdev_step14/simp_blkdev.ko
make[1]: Leaving directory `/usr/src/kernels/2.6.18-53.el5-i686'
#
没发现问题。
然后看看目前的内存状况：
# cat /proc/meminfo
...
HighTotal: 1146816 kB
HighFree: 87920 kB
LowTotal: 896356 kB
LowFree: 791920 kB
...
#
可以看出高端和低端内存分别剩余87M和791M。
然后指定size=50M加载模块后看看内存变化：
# insmod simp_blkdev.ko size=50M
# cat /proc/meminfo
...
HighTotal: 1146816 kB
HighFree: 86804 kB
LowTotal: 896356 kB
LowFree: 791912 kB
...
#
在这里我们发现剩余内存的变化不大，
这也证明了这次修改的效果，因为加载模块时不会申请用于存储数据的全部内存。
而在原先的代码中，这一步骤将使机器减少大约50M的剩余空间。
然后我们来验证读取块设备时也不会导致分配内存：
# dd if=/dev/simp_blkdev of=/dev/null
102400+0 records in
102400+0 records out
52428800 bytes (52 MB) copied, 0.376118 seconds, 139 MB/s
# cat /proc/meminfo
...
HighTotal: 1146816 kB
HighFree: 85440 kB
LowTotal: 896356 kB
LowFree: 791888 kB
...
#
剩余内存几乎没有变化，这证明了我们的设想。
然后是写设备的情况：
# dd if=/dev/zero of=/dev/simp_blkdev
dd: writing to `/dev/simp_blkdev': No space left on device
102401+0 records in
102400+0 records out
52428800 bytes (52 MB) copied, 0.542117 seconds, 96.7 MB/s
# cat /proc/meminfo
...
HighTotal: 1146816 kB
HighFree: 34116 kB
LowTotal: 896356 kB
LowFree: 791516 kB
...
#
这时剩余内存终于减少了大约50M，
这意味着驱动程序申请了大约50M的内存用于存储写入的数据。
如果向已写入的位置再次写入数据，理论上不应该造成再一次的分配，
让我们试试：
# dd if=/dev/zero of=/dev/simp_blkdev
dd: writing to `/dev/simp_blkdev': No space left on device
102401+0 records in
102400+0 records out
52428800 bytes (52 MB) copied, 0.644972 seconds, 81.3 MB/s
# cat /proc/meminfo
...
HighTotal: 1146816 kB
HighFree: 33620 kB
LowTotal: 896356 kB
LowFree: 791516 kB
...
#
结果与预想一致。
现在卸载模块：
# rmmod simp_blkdev
# cat /proc/meminfo
...
HighTotal: 1146816 kB
HighFree: 84572 kB
LowTotal: 896356 kB
LowFree: 791640 kB
...
#
我们发现被驱动程序使用的内存被释放回来了。
如果以上的实验没有让读者过瘾的话，我们来继续一个过分一些的，
也就是创建空间远远大于机器物理内存的块设备。
首先我们看看目前的系统内存状况：
# cat /proc/meminfo
...
HighTotal: 1146816 kB
HighFree: 77688 kB
LowTotal: 896356 kB
LowFree: 783296 kB
...
#
机器的总内存是2G，目前剩余的高、低端内存加起来是860M左右。
然后我们加载模块，注意一下size参数的值：
# insmod simp_blkdev.ko size=10000G
#
命令成功返回，而如果换作原先的代码，
命令出错返回......是不太可能的，
最可能的大概是内核直接panic。
这是因为申请光全部内存的操作将导致申请出错时运行的用于释放内存的代码所需要的内存都无法满足。
无论我们设置多大的块设备容量，模块加载后只要不执行写操作，
驱动程序都不会申请存储数据的内存。而这个测试：
# cat /proc/meminfo
...
HighTotal: 1146816 kB
HighFree: 75208 kB
LowTotal: 896356 kB
LowFree: 783132 kB
...
#
也证明了这一点。
现在我们看看这时的块设备情况：
# fdisk -l /dev/simp_blkdev
Disk /dev/simp_blkdev: 10737.4 GB, 10737418240000 bytes
255 heads, 63 sectors/track, 1305416 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk /dev/simp_blkdev doesn't contain a valid partition table
#
果然是10000G，这可以通过换算10737418240000 bytes得到。
而fdisk显示10737.4 GB是因为它是按照1k=1000字节、1M=1000K、1G=1000M来算的，
这种流氓的算法给硬盘厂商的缺斤少两行为提供了极好的借口。
这里省略fdisk、mkfs、mount、cp等操作，
直接用dd往这个"10000G磁盘"中写入50M的数据：
# dd if=/dev/zero of=/dev/simp_blkdev bs=1M count=50
50+0 records in
50+0 records out
52428800 bytes (52 MB) copied, 0.324054 seconds, 162 MB/s
# cat /proc/meminfo
...
HighTotal: 1146816 kB
HighFree: 23512 kB
LowTotal: 896356 kB
LowFree: 782884 kB
...
#
现在的内存情况证明我们的"10000G磁盘"为这些数据申请了50M的内存。
实验差不多了，我们卸载模块：
# rmmod simp_blkdev.
#
做完以上的实验，读者可能会有一个疑问，如果我们真的向那个"10000G磁盘"中写入了10000G的数据怎么样呢？
回答可能不太如人意，就是系统很可能会panic。
因为这个操作将迫使驱动程序吃掉全部可能获得的物理内存，并且在吃光最后那么一丁点内存之前不会发生错误，
这也意味着走到出错处理这一步的时候，系统已经几乎无可救药了。其实在此之前系统就会一次进行：
释放缓存、试图把所有的用户进程的内存换出、杀死全部能够杀死的进程等操作。
而我们的驱动程序由于被看作是内核的一部分，却不会被停止，而是在继续不停的吃掉通过上述方式释放出的可怜的内存。
试想，一个已经走到这一步的系统还有什么继续运行的可能呢？
因此，我们的程序确实需要改善以解决这个问题，因为世界上总是有一些疯狂的人在想各种办法虐待电脑。
但我们并不打算在本教程中解决它，因为这个教程中的每一章都企图为读者说明一类知识或一种方法，
而不是仅仅为了这个示例性质的程序的功能本身。
所以这一项改善就当作是留给读者的练习了。
本章通过改善块设备驱动程序实现了内存的滞后申请，
其目的在于介绍这种方法，以使它在其他的相似程序中也得以实现。
不过，这并不意味着作者希望读者把这种方法过分引用，
比如引用成平时不学习，考试前临时抱佛脚。
<未完，待续>
<script>window._bd_share_config={"common":{"bdSnsKey":{},"bdText":"","bdMini":"2","bdMiniList":false,"bdPic":"","bdStyle":"0","bdSize":"16"},"share":{}};with(document)0[(getElementsByTagName('head')[0]||body).appendChild(createElement('script')).src='http://bdimg.share.baidu.com/static/api/js/share.js?v=89860593.js?cdnversion='+~(-new Date()/36e5)];</script>
阅读(505) | 评论(0) | 转发(1) |
相关热门文章
给主人留下些什么吧！~~
评论热议
