Source-Changes-D archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/arch
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
Home |
Main Index |
Thread Index |
Old Index