linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Eric Whiting <ewhiting@amis.com>,
	akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: -mmX 4G patches feedback [numbers: how much performance impact]
Date: Wed, 7 Apr 2004 09:25:17 +0200	[thread overview]
Message-ID: <20040407072517.GA32140@elte.hu> (raw)
In-Reply-To: <20040406202548.GI2234@dualathlon.random>


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

> BTW, which is the latest 4:4 patch to use on top of 2.4? I'm porting
> the one in Andrew's rc3-mm4 in order to run the benchmark on top of
> the same kernel codebase. is that the latest one?

yeah, the one in -mm is the latest one. (right now it's out to isolate
early-bootup and ACPI problems, but it's very recent otherwise)

the 2.4 one i kept minimalistic, the latest one you can find in the
RHEL3 srpm. The 2.6 one also contains related cleanups to x86
infrastructure.

> we perfectly know that the biggest slowdown is in mysql-like and
> databases running gettimeofday, they're quite common workloads.
> Numbers were posted to the list too. vgettimeofday mitigates it.

ok. I'm not sure it's due to gettimeofday, but vgettimeofday is nice no
matter what.

> > you should also consider that while 4:4 does introduce extra TLB
> > flushes, it also removes the TLB flush at context-switch. So for
> > context-switch intensive workloads the 4:4 overhead will be smaller. (in
> 
> yes, that's also why threaded apps are hurted most. And due the
> serialized copy-user probably you shouldn't enable the threading support
> in apache2 for 4:4. Did you get the 5% slowdown with threading enabled?

it was Apache 2.0, but without threading enabled. (the default install)

> I'd expect more if you enable the threading, partly because 3:1 should
> run a bit faster with threading, and mostly because 4:4 serializes the
> copy-user. (OTOH not sure if apache does that much copy-user, in the
> past they used mmapped I/O, and mmapped I/O should scale well with
> threading on 4:4 too)

with the serialization it can get really slow. I have some copy-user
optimizations in the 2.4 patch. All it needs is a "safe" pagetable
walking function, which doesnt get confused by things like large pages. 
If this function fails then we try user_pages() - to make sure we catch
mappings not present in the pagetables (e.g. hugepages on some
platforms). Another problem are IO vmas. It might not be legal to touch
them via the user-copy functions.

but if it's possible to walk the pagetables without having to look at
the vma tree then the copy-user functions can be done lockless. This
feature is not in the 2.6 patch yet.

> > But for pure userspace code (which started this discussion), where
> > userspace overhead dominates by far, the cost is negligible even with
> > 1000Hz.
> 
> I thought hz 1000 would hurt more than %0.02 given 900 irqs per second
> themselfs wastes 1% of the cpu, but I may very well be wrong about that

the slowdown is higher: %0.2. This is the table again:

   1000Hz:               -1.08%
   1000Hz + PAE:         -1.08%
   1000Hz + 4:4:         -1.11%
   1000Hz + PAE + 4:4:   -1.39%

so we slow down from -1.08% to -1.39%, by -0.21%.

> (it's just your previous post wasn't convincing due the apparently too
> artificial testcase), [...]

as i mentioned it before, i did generate a dTLB testcase too - see the
simple code below. (it's hardcoded to my setup, the # of TLBs is
slightly below the real # of TLBs to not trash them.) It simply loops
through 60 pages and touches them. Feel free to modify it to have more
pages to see the effect on TLB-trashing apps [that should be a smaller
effect]. Also you can try other effects: nonlinear access to the pages,
and/or a more spread out layout of the working set.

but please be extremely careful with this testcase. It needs static
linking & init= booting to produce stable, comparable numbers. I did
this for a couple of key kernels and made sure the effect is the same as
in the simple loop_print.c case, but it's a real PITA to ensure stable
numbers.

	Ingo

#include <stdlib.h>
#include <stdio.h>
#include <time.h>

#define rdtscll(val) \
     __asm__ __volatile__ ("rdtsc;" : "=A" (val))

#define SECS 10ULL

#define TLBS 60

volatile char pages[TLBS*4096];

void touch_dtlbs(void)
{
	volatile char x;
	int i;

	for (i = 0; i < TLBS; i++)
		x = pages[i*4096];
}

main () {
	unsigned long long start, now, mhz = 525000000, limit = mhz * SECS;
	unsigned int count;

	printf("dtlb-intense workload:\n");
	memset(pages, 1, TLBS*4096);
repeat:
	rdtscll(start);
	count = 0;
	for (;;) {
		touch_dtlbs();
		count++;
		rdtscll(now);
		if (now - start > limit)
			break;
	}
	printf("speed: %d loops.\n", count/SECS); fflush(stdout);
	goto repeat;
}

  parent reply	other threads:[~2004-04-07  7:28 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-05 16:36 -mmX 4G patches feedback Eric Whiting
2004-04-05 17:46 ` Andrea Arcangeli
2004-04-05 21:35   ` Eric Whiting
2004-04-05 22:16     ` Andrea Arcangeli
2004-04-06 11:55       ` -mmX 4G patches feedback [numbers: how much performance impact] Ingo Molnar
2004-04-06 14:49         ` Eric Whiting
2004-04-06 15:59         ` Andrea Arcangeli
2004-04-06 16:13           ` Arjan van de Ven
2004-04-06 16:39             ` Andrea Arcangeli
2004-04-06 17:24           ` Ingo Molnar
2004-04-06 17:57             ` Andrea Arcangeli
2004-04-07 22:54               ` Martin J. Bligh
2004-04-07 22:50                 ` Andrea Arcangeli
2004-04-06 19:25           ` Ingo Molnar
2004-04-06 20:25             ` Andrea Arcangeli
2004-04-07  6:03               ` Andrea Arcangeli
2004-04-07  6:46                 ` Ingo Molnar
2004-04-07  7:23                   ` Andrea Arcangeli
2004-04-07  8:23                     ` Ingo Molnar
2004-04-07 21:35                       ` Andrea Arcangeli
2004-04-07 17:27                   ` Andrea Arcangeli
2004-04-07  7:25               ` Ingo Molnar [this message]
2004-04-07 21:39                 ` Andrea Arcangeli
2004-04-07 22:58             ` Martin J. Bligh
2004-04-07 23:01               ` Andrea Arcangeli
2004-04-07 23:21                 ` Martin J. Bligh
2004-04-07 23:18                   ` Andrea Arcangeli
2004-04-07 23:34                     ` Martin J. Bligh
2004-04-08  0:18                       ` Andrea Arcangeli
2004-04-08  6:24                         ` Martin J. Bligh
2004-04-08 21:59                           ` Andrea Arcangeli
2004-04-08 22:19                             ` Martin J. Bligh
2004-04-08 22:19                               ` Andrea Arcangeli
2004-04-08 23:14                                 ` Martin J. Bligh
2004-04-08 23:22                                   ` Andrea Arcangeli
2004-04-08 23:42                                     ` Martin J. Bligh
2004-04-08 23:49                                       ` Andrea Arcangeli
2004-04-07 21:19       ` -mmX 4G patches feedback Martin J. Bligh
2004-04-07 21:49         ` Andrea Arcangeli
  -- strict thread matches above, loose matches on Subject: below --
2004-04-06 17:59 -mmX 4G patches feedback [numbers: how much performance impact] Manfred Spraul
2004-04-06 18:41 ` Andrea Arcangeli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040407072517.GA32140@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@osdl.org \
    --cc=andrea@suse.de \
    --cc=ewhiting@amis.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).