From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keshav Darak Subject: Re: PATCH: Hugepage support for Domains booting with 4KB pages Date: Tue, 22 Mar 2011 11:05:14 -0700 (PDT) Message-ID: <970792.33869.qm@web59602.mail.ac4.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Konrad Rzeszutek Wilk Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org =0AKonrad,=0A=0AThanks for reviewing the patch.=0A=0A>> We have implemented= hugepage support for guests in following manner=0A>> =0A>> In=0A>>=A0 our = implementation we added a parameter hugepage_num which is specified=0A>>=A0= in the config file of the DomU. It is the number of hugepages that the =0A= >> guest is guaranteed to receive whenever the kernel asks for hugepage by = =0A>> using its boot time parameter or reserving after booting (eg. Using e= cho=0A>>=A0 XX > /proc/sys/vm/nr_hugepages). During creation of the domain = we =0A>> reserve MFN's for these hugepages and store them in the list. The = =0A=0A>There is bootup option for normal Linux kernels to set that up. Was= =0A>that something you could use?=0A=0Aya, it can be used too, to allocate = the hugepages.=0A=0A>> =0A>> static inline int arch_prepare_hugepage(struct= page *page)=0A>> {=0A>>index f46c340..00c489a 100644=0A>>--- a/arch/x86/mm= /hugetlbpage.c=0A>>+++ b/arch/x86/mm/hugetlbpage.c=0A>>@@ -147,8 +147,7 @@ = pte_t *huge_pte_alloc(struct mm_struct *mm,=0A>> =A0=A0=A0 =A0=A0=A0 =A0=A0= =A0 pte =3D (pte_t *) pmd_alloc(mm, pud, addr);=0A>> =A0=A0=A0 =A0=A0=A0 }= =0A>> =A0=A0=A0 }=0A>>-=A0=A0=A0 BUG_ON(pte && !pte_none(*pte) && !pte_huge= (*pte));=0A>>-=0A>>+=A0=A0=A0 BUG_ON(pte && !pte_none(*pte) && !((*pte).pte= & (_AT(pteval_t, 1)<<7)));=0A=0A>Ugh. That is horrible.=0A=0A>why can't yo= u use 'pte_huge' ? Is it b/c of this=0A> * (We should never see kernel mapp= ings with _PAGE_PSE set,=0A> * but we could see hugetlbfs mappings, I think= .).=0A> */=0A=0AHere actually we don't known the exact reason, but when pte= _huge was used the BUG_ON was called even though the PSE bit was set, so we= had to rewrite the BUG_ON testing the 7th bit.there could be better ways t= o do it, But we couldn't find the exact reasons why was it(pte_huge) return= ing 0 even when the pte was a huge_pte. =0A=0A=0Awe will try to resolve = other issues with the patch as soon as possible. =0A=0A--=0AKeshav Darak=0A= Kaustubh Kabra=0AAshwin Vasani=0AAditya Gadre=0A=0A=0A