On 24.07.2010 18:40, Antti Kantee wrote: > On Sat Jul 24 2010 at 15:23:50 +0000, Quentin Garnier wrote: >>> PAE is a "bridge technology", interesting only for few systems. >>> Users of low-end i386 systems would be penalized, and most users >>> of boxes with >4G memory would gain nothing because they run >>> a 64-bit system anyway. >>> So, imho, no kernel overhead is acceptable. >> >> Well, that's one opinion. My own, probably just as humble, is that such >> a gaping ABI incompatibility is completely unacceptable, especially >> after all the work that has been done to make some kernel subsystems a >> little bit more responsible regarding ABI. >> >> I'm really curious to see some actual measurements about that alleged >> overhead. The way I see it right now, we have a known lethal ABI >> incompatibility versus an alleged overhead of unknown size. > > Didn't anyone else read the mail from a week or so ago containing detailed > measurements of the overhead?
It measures overhead of PAE, not turning paddr_t to 64 bits on !PAE i386. I don't think that paddr_t moving to 64 bits add much overhead. I would rather incriminate TLB flushes and 64 bits atomic ops... > (I'm not 100% sure if I believe the results without further analysis, > but at least there are benchmarks) I am not sure that benchmarking is a matter of believing :) I could make something out of the phoronix tests [1] and track performance regressions on a revision (or week) basis, atf-style, but as always, the hardest part about benchmarks is interpretation, not running them (once everything is in place) While sysbench announces 20% less memory bandwidth, build.sh runs have no more than 3% overhead with PAE. So, hmm, between one specific measurement and real world use... there is quite a gap. -- Jean-Yves Migeon jeanyves.mig...@free.fr