From: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
To: linux-ia64@vger.kernel.org
Subject: RE: [PATCH] RFC : Page table macros
Date: Wed, 16 Nov 2005 18:31:16 +0000 [thread overview]
Message-ID: <200511161831.jAGIVGg12799@unix-os.sc.intel.com> (raw)
In-Reply-To: <20051116050037.GF2440@cse.unsw.EDU.AU>
Robin Holt wrote on Wednesday, November 16, 2005 4:42 AM
> On Tue, Nov 15, 2005 at 10:09:46PM -0800, Chen, Kenneth W wrote:
> > Ian Wienand wrote on Tuesday, November 15, 2005 9:01 PM
> > > Please find below a patch to make some page table modifications
> > > similar to something I posted earlier before the 4 level stuff.
> >
> > I'm not so sure about the change in ivt.S. It makes the code a
> > lot harder to read. After all, the asm code in ivt.S is very
> > low level and deal with all the low level detail anyway. You
> > aren't going to get away with more macros.
>
> I disagree. I think we could make significant improvements in
> readability. I don't think this patch is there, but it at
> least starts the ball rolling.
Besides the readability issue I have, I have a bigger issue with the
patch that it introduces *buggy* code. For example:
-(p7) dep r17=r17,r19,(PAGE_SHIFT-3),3 // put region number bits in place
+(p7) dep r17=r17,r19,PGD_INDEX_BITS,PGD_ENTRY_BITS // put region number bits in place
The fact that we take 3 bits out of source is not because pgd entry
is 3 bit long, but rather, region bits is 3! The fact that we deposit
into bit position 11 is because we put it as the most significant bits
of the pgd index, not because pgd index has 11 bits.
Put aside the buggy code argument, let's look at the macro: pgd_offset(),
pud_offset, and pmd_offset() are all pointer calculation, everyone knows
what pointer size is (if you don't, you are in trouble and shouldn't be
mucking around with ivt.S :-) what do you mean by defining:
+#define PMD_ENTRY_BITS 3
+#define PGD_ENTRY_BITS 3
Size of pointer? Then why another indirection? It simply can't be more
explicit to know that size of pointer is 3 bit and such constant is used
in the index calculation. Perhaps what you should do is to add a
comments in the beginning of vhpt_miss handler and say that we are pretty
much doing:
pgd = pgd_offset(mm, addr);
if (pgd_present(*pgd)) {
pud = pud_offset(pgd, addr);
if (pud_present(*pud)) {
pmd = pmd_offset(pud, addr);
if (pmd_present(*pmd))
pte = pte_offset_map(pmd, addr);
}
}
and be done with it.
Here is another example:
- cmp.eq p6,p7=5,r17 // is IFA pointing into to region 5?
+ cmp.eq p6,p7=5,r17 // is faulting address in region 5?
What do you mean by "faulting address"? Vhpt_miss handler handles two
faulting addresses, tlb for ifa and the pte pointer. This change muddy
the confusion while the original comments is very explicit about which
one it is looking at.
- Ken
next prev parent reply other threads:[~2005-11-16 18:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-16 5:00 [PATCH] RFC : Page table macros Ian Wienand
2005-11-16 6:09 ` Chen, Kenneth W
2005-11-16 12:41 ` Robin Holt
2005-11-16 18:31 ` Chen, Kenneth W [this message]
2005-11-16 21:03 ` Ian Wienand
2005-11-16 22:29 ` Chen, Kenneth W
2005-11-16 22:41 ` Ian Wienand
2005-11-16 22:53 ` Chen, Kenneth W
2005-11-16 23:05 ` Luck, Tony
2005-11-16 23:08 ` Peter Chubb
2005-11-16 23:19 ` Ian Wienand
2005-11-18 6:23 ` Ian Wienand
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=200511161831.jAGIVGg12799@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