From: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
To: 'David Gibson' <david@gibson.dropbear.id.au>
Cc: 'Hugh Dickins' <hugh@veritas.com>,
"Luck, Tony" <tony.luck@intel.com>,
linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: RE: [patch] fix ia64 hugetlb_free_pgd_range
Date: Fri, 24 Feb 2006 03:05:23 +0000 [thread overview]
Message-ID: <200602240305.k1O35Ng06352@unix-os.sc.intel.com> (raw)
In-Reply-To: <20060224024431.GC28368@localhost.localdomain>
In-Reply-To: <200602240145.k1O1jEg05475@unix-os.sc.intel.com>
David Gibson wrote on Thursday, February 23, 2006 6:45 PM
> However... I suspect in fact that the transformations should be
> unconditional.
No, that won't be correct.
> The whole address scaling thing that ia64 does for
> hugepages is extremely confusing, but since floor and ceiling are just
> used for bounds checking on the inner functions, shouldn't they be
> transformed to the same scale as addr and end, even if that's not
> actually a true address (hugepage or otherwise).
Think of multiple page size support, the way we do it on ia64 is
effective have different PAGE_SHIFT for normal page and hugetlb
page. Normal page has page shift of 14 bits (of 16K page size).
Hugetlb page has page shift of 28 bits (of 256MB page size).
For any address, regardless whether it is normal/hugetlb page,
they all have full 3 level (or 4 level page table). So for hugetlb
address, pgd/pud/pmd/pte index are off by (28-14) bits compare
to normal page. We just transform the address so all the generic
code can be applied. It's sort of selling you a wood looking
vinyl car stick shift.
- Ken
next prev parent reply other threads:[~2006-02-24 3:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-24 1:45 [patch] fix ia64 hugetlb_free_pgd_range Chen, Kenneth W
2006-02-24 2:44 ` 'David Gibson'
2006-02-24 3:05 ` Chen, Kenneth W [this message]
2006-02-24 4:05 ` 'David Gibson'
2006-02-24 6:30 ` Chen, Kenneth W
2006-02-27 0:27 ` David Gibson
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=200602240305.k1O35Ng06352@unix-os.sc.intel.com \
--to=kenneth.w.chen@intel.com \
--cc=david@gibson.dropbear.id.au \
--cc=hugh@veritas.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tony.luck@intel.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