linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ben LaHaise <bcrl@redhat.com>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Kanoj Sarcar <kanoj@google.engr.sgi.com>,
	linux-mm@kvack.org, torvalds@transmeta.com
Subject: Re: [PATCH] workaround for lost dirty bits on x86 SMP
Date: Tue, 12 Sep 2000 12:54:03 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.21.0009121250510.7545-100000@devserv.devel.redhat.com> (raw)
In-Reply-To: <20000912112438.C28418@redhat.com>

On Tue, 12 Sep 2000, Stephen C. Tweedie wrote:

> Of course it won't, because you aren't testing the new behaviour!
> Anonymous pages are always dirty, and shared mmaped pages in
> MAP_PRIVATE regions are always clean.  The only place where you need
> to track the dirty bit dynamically is when you use shared writeable
> mmaps --- can you measure a performance change there?

Here's a more realistic test, and yes it does extract a heavy performance
hit -- unpatched read then write to 1 byte of 1GB of pages:

size is 1073741825
addr = 0x4010f000
read fault test: start=29670620301256 stop=29670945360465, elapsed=325059209
write fault test: start=29670945400339 stop=29671024199394, elapsed=78799055

patched:

size is 1073741825
addr = 0x4010f000
read fault test: start=135059091263 stop=135383514415, elapsed=324423152
write fault test: start=135383569394 stop=135664481836, elapsed=280912442

So, let's see what can be done to speed up the clean to dirty fault
path...  (more later)

		-ben

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

  reply	other threads:[~2000-09-12 16:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-12  0:43 Ben LaHaise
2000-09-12  0:59 ` Kanoj Sarcar
2000-09-12  1:36   ` bcrl
2000-09-12  1:56     ` Rik van Riel
2000-09-12  2:34     ` Kanoj Sarcar
2000-09-12  3:39       ` Benjamin C.R. LaHaise
2000-09-12  6:13         ` Kanoj Sarcar
2000-09-12 10:24     ` Stephen C. Tweedie
2000-09-12 16:54       ` Ben LaHaise [this message]
2000-09-15 19:56 ` Linus Torvalds

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=Pine.LNX.4.21.0009121250510.7545-100000@devserv.devel.redhat.com \
    --to=bcrl@redhat.com \
    --cc=kanoj@google.engr.sgi.com \
    --cc=linux-mm@kvack.org \
    --cc=sct@redhat.com \
    --cc=torvalds@transmeta.com \
    /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