Linux 2.6.39-rc3的一个插曲

2011年4月12日，Linux 2.6.39-rc3发布了，Linus Torvalds写了一个发布邮件，其中包含了一个长长的为这个版本做过贡献的人员名单，这个名单中有很多看上去应该是中国人的名字，我挺为他们感到骄傲的（不知道你是否还记得以前本站的”Linux是由谁写的“）。

 1 2 3 4 5 6 7 8 9 10 11 12 13 diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c index 86d1ad4..3b6a9d5 100644 --- a/arch/x86/kernel/aperture_64.c +++ b/arch/x86/kernel/aperture_64.c @@ -83,7 +83,7 @@ static u32 __init allocate_aperture(void)       * so don't use 512M below as gart iommu, leave the space for kernel       * code for safe       */ -   addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20); +   addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21);      if (addr == MEMBLOCK_ERROR || addr + aper_size > 0xffffffff) {          printk(KERN_ERR              "Cannot allocate aperture memory hole (%lx,%uK)/n",

• 为什么全都是Magic Numbers？
• 为什么0×80000000就那么特殊？
• 为什么我们这样改就行？

This kind of “I broke things, so now I will jiggle things randomly until they unbreak” is not acceptable. 这种“我把事搞砸了，就随意地调整直到事情又工作”的方式是不可接受的。

Don’t just make random changes. There really are only two acceptable models of development: “think and analyze” or “years and years of testing on thousands of machines”. Those two really do work.

Yinghai, we have had this discussion before, and dammit, you need to understand the difference between “understanding the problem” and “put in random values until it works on one machine”.

Yinghai，我们以前谈过这个事，该死的，你真的需要明白“理解一个错误”和“设一个随意的值直到其正常工作”的区别。

There was absolutely _zero_ analysis done. You do not actually understand WHY the numbers matter. You just look at two random numbers, and one works, the other does not. That’s not “analyzing”. That’s just “random number games”.

If you cannot see and understand the difference between an actual analytical solution where you _understand_ what the code is doing and  why, and “random numbers that happen to work on one machine”, I don’t know what to tell you.

Let me repeat my point one more time.

You have TWO choices. Not more, not less:

- choice #1: go back to the old allocation model. It’s tested. It doesn’t regress. Admittedly we may not know exactly _why_ it works, and it might not work on all machines, but it doesn’t cause regressions (ie the machines it doesn’t work on it _never_ worked on).

And this doesn’t mean “old value for that _one_ machine”. It means “old value for _every_ machine”. So it means we revert the whole bottom-down thing entirely. Not just “change one random number so that the totally different allocation pattern happens to give the same result on one particular machine”.

- Choice #2: understand exactly _what_ goes wrong, and fix it analytically (ie by _understanding_ the problem, and being able to solve it exactly, and in a way you can argue about without having to resort to “magic happens”).

- 选择二：真正搞清楚为什么会错，并且有分析地修改他（理解问题才能真正解决之，并且，只有没有“魔法发生”的时候你才可以来争论）

Now, the whole analytic approach (aka “computer sciency” approach), where you can actually think about the problem without having any pesky “reality” impact the solution is obviously the one we tend to prefer. Sadly, it’s seldom the one we can use in reality when it comes to things like resource allocation, since we end up starting off with often buggy approximations of what the actual hardware is all about (ie broken firmware tables).

So I’d love to know exactly why one random number works, and why another one doesn’t. But as long as we do _not_ know the “Why” of it, we will have to revert.

It really is that simple. It’s _always_ that simple.

So the numbers shouldn’t be “magic”, they should have real explanations. And in the absense of real explanation, the model that works is “this is what we’ve always done”. Including, very much, the whole allocation order. Not just one random number on one random machine.

Linus

—– 更新2011/04/27—–

1. 你的老板给你压力，让你不得不乱fix，
2. 你认同只要时间紧bug是可以乱fix的。

08-17 474
08-02 3万+
08-08 116

• 非常没帮助
• 没帮助
• 一般
• 有帮助
• 非常有帮助