Re: CVS commit: src/sys/arch

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

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.migeon%free.fr@localhost