Re: -mmX 4G patches feedback [numbers: how much performance impact]

[Ingo Molnar <mingo@elte.hu>]

* Andrea Arcangeli <andrea@suse.de> wrote:

> >         http://redhat.com/~mingo/4g-patches/loop_print.c
> 
> loop print does no memory access at all, it just loops forever, [...]

expecting such a reply my first mail already answers this point:

[**] i also repeated the measurements with a d-TLB-intense workload,
     which should be the worst-case, considering the TLB flushes. [the
     workload iterated through #dTLB pages and touched one byte in each
     page.] This added +0.02% overhead in the 1000Hz + PAE case. (just
     at the statistical noise limit).

i just didnt expect your apparent inability to read.

(note that this dTLB test did the worst-case test by looping through
#dTLB pages (and not more), and thus maximizing the slowdown effect of
any TLB flushes. I also tested other workloads, such as
data-cache-intensive and memory-intensive workloads, with similar
results.)

> I simply heard the effect was less visible on PIII than on more recent
> cpus, but maybe that was wrong.

my mail also answers your other point:

    [...] I used a 525 MHz Celeron for testing. The results are
    similar on faster x86 systems.

yes, i did check a P4 CPU too. Plus:

> [...] no surprise at all you get very little slowdown no matter how
> many tlb flushes happens.

contrary to your claim, 90% of the TLB-flush overhead is in fact
upfront, at the time of the cr3 write, in the irq handler. So
loop_print.c will already show 90% of the overhead - and it's by far the
simplest and most stable measurement utility.

(anyway, feel free to reproduce and post contrary results here. The onus
is on you. And if you think i'm upset about your approach to this whole
issue then you are damn right.)

	Ingo