From: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
To: linux-ia64@vger.kernel.org
Subject: RE: accessed/dirty bit handler tuning
Date: Mon, 13 Mar 2006 20:14:19 +0000 [thread overview]
Message-ID: <200603132014.k2DKEHg25250@unix-os.sc.intel.com> (raw)
In-Reply-To: <44157CF1.5060902@bull.net>
Luck, Tony wrote on Monday, March 13, 2006 12:05 PM
> >Hmm, I think another alternative is to rip out all the itc insertion
> >code and let the hardware page walker do the "dirty" job. Because it
> >is known and architected to be atomic-read-and-insert and is also
> >known to honor ptc.g while atomic-read-and-insert is in-flight (i.e.,
> >won't insert tlb entry).
>
> Can we get some perf. numbers ... this will take each dirty fault twice
> (though the second should be fast if VHPT does it's job). This might
> be slower than putting in the srlz.d that Zoltan wants.
I don't have any numbers ... Though I've measured 5 cycles hpw insert
latency. It ought be faster than srlz.d.
On the other hand, the behavior of itc with respect to ptc.g is still up
in the air pending an query from ia64 hardware architects. But the more
I read the SDM, the more it looks like a statement of actual processor
behavior instead of a statement for software requirement.
So going either way is a pre-matured decision, I guess.
- Ken
next prev parent reply other threads:[~2006-03-13 20:14 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-13 14:08 accessed/dirty bit handler tuning Zoltan Menyhart
2006-03-13 16:31 ` Christoph Lameter
2006-03-13 16:55 ` Zoltan Menyhart
2006-03-13 19:46 ` Chen, Kenneth W
2006-03-13 20:05 ` Luck, Tony
2006-03-13 20:14 ` Chen, Kenneth W [this message]
2006-03-13 22:53 ` Chen, Kenneth W
2006-03-14 10:12 ` Zoltan Menyhart
2006-03-14 19:33 ` Chen, Kenneth W
2006-03-15 13:29 ` Zoltan Menyhart
2006-03-15 17:37 ` Chen, Kenneth W
2006-03-16 9:57 ` Zoltan Menyhart
2006-03-16 10:19 ` Luck, Tony
2006-03-16 19:12 ` Chen, Kenneth W
2006-03-29 8:11 ` Zoltan Menyhart
2006-03-29 8:28 ` Chen, Kenneth W
2006-03-29 13:37 ` Zoltan Menyhart
2006-03-29 17:01 ` Zoltan Menyhart
2006-03-29 22:57 ` Luck, Tony
2006-03-29 22:59 ` Chen, Kenneth W
2006-03-30 15:13 ` Zoltan Menyhart
2006-03-31 16:23 ` Zoltan Menyhart
2006-03-31 19:08 ` Chen, Kenneth W
2006-03-31 21:18 ` Zoltan Menyhart
2006-03-31 21:51 ` Chen, Kenneth W
2006-03-31 22:14 ` Chen, Kenneth W
2006-03-31 22:57 ` Zoltan Menyhart
2006-04-03 8:46 ` Zoltan Menyhart
2006-04-03 13:45 ` Zoltan Menyhart
2006-04-03 15:49 ` Luck, Tony
2006-04-03 15:57 ` Luck, Tony
2006-04-03 16:33 ` Zoltan Menyhart
2006-04-03 16:42 ` David Mosberger-Tang
2006-04-03 17:23 ` Zoltan Menyhart
2006-04-03 17:50 ` Luck, Tony
2006-04-03 18:27 ` Christoph Lameter
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=200603132014.k2DKEHg25250@unix-os.sc.intel.com \
--to=kenneth.w.chen@intel.com \
--cc=linux-ia64@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