From: Zoltan Menyhart <Zoltan.Menyhart@free.fr>
To: linux-ia64@vger.kernel.org
Subject: RE: accessed/dirty bit handler tuning
Date: Fri, 31 Mar 2006 16:23:00 +0000 [thread overview]
Message-ID: <442D5764.5090903@free.fr> (raw)
In-Reply-To: <44157CF1.5060902@bull.net>
Ken wrote:
> cpu0 cpu1 cpu2
> Vhpt miss:
> walk page table
> free_pgtables
> ptc.g fault address
> ptc.g hash address
> pud_alloc/pmd_alloc
> new page instantiation
> itc.d faulting address
> itc.d hash address
> read pte
> kill tlb for fault addr
> rfi
Let's apply the same logic to the dirty bit handler.
Assume a nested TLB miss, i.e. we dig up the PTE entry in the same way as
we do in "vhpt_miss" (in physical addressing mode):
rx = ... -> pgd[i] -> pud[j] -> pmd[k] -> pte[l]
(and some NULL pointer verifications)
Having inserted the new PTE (and the srlz.d is done), we re-read the
PTE value only.
What makes it sure that the PTE address is still valid when we re-read the
PTE value (we are still in physical addressing mode)?
Should not we re-read the complete pgd ... pte chain as we do in "vhpt_miss"?
Should not we insert the TLB entry for the relevant virtual page table page
as we do in "vhpt_miss" (it's an efficiency issue only)?
Thanks,
Zoltan
next prev parent reply other threads:[~2006-03-31 16:23 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
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 [this message]
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=442D5764.5090903@free.fr \
--to=zoltan.menyhart@free.fr \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.