The title is a bit misleading. If I understood Linus correctly he is saying that a page fault on modern processors is costly. There is nothing the OS can do
to make a page fault itself (or iret) faster.
> It's interesting, because the kernel software overhead
>for looking up the page and putting it into the page
>tables is actually much lower. In my worst-case situation
>(admittedly a pretty made up case where we just end up
>mapping the fixed zero-page), those 1050 cycles is
>actually 80.7% of all the CPU time.
Page faults that don't happen are free. If the OS can find ways of reducing the number of them, that's a way of speeding up the average "time there would have been a page fault"... you're right that the title is misleading, though.
Agreed, given one is 32 bit memory addressing and the other 64 bit. You would expect the 64 bit to be upto twice as long and adding optimisations in the middle, but not equal. After all a 32 bit memory address is twice as much as a 64 bit one to handle behind the scene.
Also he only used one compiler and would test with another compiler to confirm the results. Just to eliminate a possible compiler quirk in a quick way compared to checking the machine code.
