.. Kenneth Lee 版权所有 2019-2020
:Authors: Kenneth Lee :Version: 1.0
大成若缺
最近有一个这样的讨论，有个项目为了提高性能，要把一个嵌入式的产品的业务代码放在 Linux内核里面。这个产品需要一个很大的Buffer，分配这个Buffer的模块里面发现有这样 的代码：::
if (buffer_size > 4 * MB) {
pr_err("too much memory\n")
return -ENOMEM;
}
buffer = kmalloc(buffer_size, GFP_KERNEL);
...
我就好奇了，为什么要限制自己的buffer的大小在4M以下呢？后来一问，原来作者是这样 考量的，Linux由于slab算法的限制，内核内存分配不能超过4M，超过就失败了。
这我就奇怪了，Linux自己有限制，关你什么事？你返回失败，你说返回失败就好了，你在 这里自作聪明提前给他判断了，以后他支持更多的时候（实际上这个东西是可以配置的） ，你到处去改你这种代码吗？
这是一种非常常见的缺乏架构控制的，以管理为主的产品现实。很多开源开发者或者学生 可能很难理解这种情况，因为你们没有产品压力。一个大系统，已经上线了，在一线遇到 问题，要增加需求，事情交到你手上，你只懂这个系统的一小部分，怎么办？把所有问题 都在你的范围内解决就好了。
所以，很多人觉得我们国内发展不出大的系统（比如操作系统），是“技术”不够，其实这 个理解是不对的，国内很多软件系统发展到一定的程度就无法发展了，是因为我们没有架 构能力，多余的依赖加得太多，很快就加不上去了。你看到我们很多系统都是拿着老外的 开源系统建的，他们觉得自己看得懂这些代码，还嫌人家写得迂腐，“没有产品思维”，觉 得自己比别人做得更好，里面的技术都能搞定，要重写一个分分钟的事，其实他们根本就 做不到。他们做的每个模块都面面俱到。但每个模块都面面俱到的系统本身，是不“面面俱 到”的。你玩乐高积木，那得有凹有凸才能搭在一起的，都是凸起来的，这就无法拼装。
架构这种东西，简单而无名。业务模块不该为kmalloc做预判，不预判就对了。知道 kmalloc的限制，选择cma进行内存预留解决这个问题就好了。平平淡淡，不显山不露水。 看起来好多破绽，但就是可以不断接受新的逻辑进来，满足实际的需要，像滚雪球一样越 滚越大。但如果架构本身求名，每个地方深怕没有代码跳出来张扬，到处都要表现自己“懂 得多”，“都能处理”，架构就变成模块设计，把模块变成凸起来的东西，就和架构设计的目 标背道而驰了。
这就叫大成若缺。