Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1765928Ab3DEBPH (ORCPT ); Thu, 4 Apr 2013 21:15:07 -0400 Received: from mail-oa0-f41.google.com ([209.85.219.41]:42586 "EHLO mail-oa0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1765909Ab3DEBPF (ORCPT ); Thu, 4 Apr 2013 21:15:05 -0400 Message-ID: <515E2592.7020607@gmail.com> Date: Fri, 05 Apr 2013 09:14:58 +0800 From: Simon Jeons User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Michal Hocko CC: Linux Memory Management List , Andrew Morton , Mel Gorman , Hugh Dickins , KOSAKI Motohiro , Andi Kleen , Linux kernel Mailing List , Naoya Horiguchi , David Rientjes Subject: Re: [RFC][PATCH 0/9] extend hugepage migration References: <1361475708-25991-1-git-send-email-n-horiguchi@ah.jp.nec.com> <5148F830.3070601@gmail.com> <1363815326-urchkyxr-mutt-n-horiguchi@ah.jp.nec.com> <514A4B1C.6020201@gmail.com> <20130321125628.GB6051@dhcp22.suse.cz> <514B9BD8.9050207@gmail.com> <20130322081532.GC31457@dhcp22.suse.cz> In-Reply-To: <20130322081532.GC31457@dhcp22.suse.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2315 Lines: 57 Hi Michal, On 03/22/2013 04:15 PM, Michal Hocko wrote: > [getting off-list] > > On Fri 22-03-13 07:46:32, Simon Jeons wrote: >> Hi Michal, >> On 03/21/2013 08:56 PM, Michal Hocko wrote: >>> On Thu 21-03-13 07:49:48, Simon Jeons wrote: >>> [...] >>>> When I hacking arch/x86/mm/hugetlbpage.c like this, >>>> 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? >>> How is this related to the patch set? >>> Please _stop_ distracting discussion to unrelated topics! >>> >>> Nothing personal but this is just wasting our time. >> Sorry kindly Michal, my bad. >> Btw, could you explain this question for me? very sorry waste your time. > Your CPU has to support GB pages. You have removed cpu_has_gbpages test > 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. But after hacking, there is /sys/kernel/mm/hugepages/hugepages-*, and have equal number of 32MB huge pages which I set up in boot parameter. If there is no page table level to support them, how can them present? I can hacking this successfully in ubuntu, but not in fedora. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/