[getting off-list]
On Fri 22-03-13 07:46:32, Simon Jeons wrote:Hi Michal,Your CPU has to support GB pages. You have removed cpu_has_gbpages test
On 03/21/2013 08:56 PM, Michal Hocko wrote:
On Thu 21-03-13 07:49:48, Simon Jeons wrote:Sorry kindly Michal, my bad.
[...]
When I hacking arch/x86/mm/hugetlbpage.c like this,How is this related to the patch set?
diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
index ae1aa71..87f34ee 100644
--- a/arch/x86/mm/hugetlbpage.c
+++ b/arch/x86/mm/hugetlbpage.c
@@ -354,14 +354,13 @@ hugetlb_get_unmapped_area(struct file *file,
unsigned long addr,
#endif /*HAVE_ARCH_HUGETLB_UNMAPPED_AREA*/
-#ifdef CONFIG_X86_64
static __init int setup_hugepagesz(char *opt)
{
unsigned long ps = memparse(opt, &opt);
if (ps == PMD_SIZE) {
hugetlb_add_hstate(PMD_SHIFT - PAGE_SHIFT);
- } else if (ps == PUD_SIZE && cpu_has_gbpages) {
- hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT);
+ } else if (ps == PUD_SIZE) {
+ hugetlb_add_hstate(PMD_SHIFT - PAGE_SHIFT+4);
} else {
printk(KERN_ERR "hugepagesz: Unsupported page size %lu M\n",
ps >> 20);
I set boot=hugepagesz=1G hugepages=10, then I got 10 32MB huge pages.
What's the difference between these pages which I hacking and normal
huge pages?
Please _stop_ distracting discussion to unrelated topics!
Nothing personal but this is just wasting our time.
Btw, could you explain this question for me? very sorry waste your time.
and added a hstate for order 13 pages which is a weird number on its
own (32MB) because there is no page table level to support them.