|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] PATCH: Hugepage support for Domains booting with 4KB pag
Konrad,
Thanks for reviewing the patch.
>> We have implemented hugepage support for guests in following manner
>>
>> In
>> our implementation we added a parameter hugepage_num which is specified
>> in the config file of the DomU. It is the number of hugepages that the
>> guest is guaranteed to receive whenever the kernel asks for hugepage by
>> using its boot time parameter or reserving after booting (eg. Using echo
>> XX > /proc/sys/vm/nr_hugepages). During creation of the domain we
>> reserve MFN's for these hugepages and store them in the list. The
>There is bootup option for normal Linux kernels to set that up. Was
>that something you could use?
ya, it can be used too, to allocate the hugepages.
>>
>> static inline int arch_prepare_hugepage(struct page *page)
>> {
>>index f46c340..00c489a 100644
>>--- a/arch/x86/mm/hugetlbpage.c
>>+++ b/arch/x86/mm/hugetlbpage.c
>>@@ -147,8 +147,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
>> pte = (pte_t *) pmd_alloc(mm, pud, addr);
>> }
>> }
>>- BUG_ON(pte && !pte_none(*pte) && !pte_huge(*pte));
>>-
>>+ BUG_ON(pte && !pte_none(*pte) && !((*pte).pte & (_AT(pteval_t, 1)<<7)));
>Ugh. That is horrible.
>why can't you use 'pte_huge' ? Is it b/c of this
> * (We should never see kernel mappings with _PAGE_PSE set,
> * but we could see hugetlbfs mappings, I think.).
> */
Here 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 to do it, But we couldn't
find the exact reasons why was it(pte_huge) returning 0 even when the pte was a
huge_pte.
we will try to resolve other issues with the patch as soon as possible.
--
Keshav Darak
Kaustubh Kabra
Ashwin Vasani
Aditya Gadre
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|