|  |  | 
  
    |  |  | 
 
  |   |  | 
  
    |  |  | 
  
    |  |  | 
  
    |   xen-devel
Re: [Xen-devel] PATCH: Hugepage support for Domains booting with 4KB	pag 
| Keshav,
There is already optional support for superpage allocations and mappings for
PV guests in the hypervisor and toolstack. See the opt_allow_superpages
boolean flag in the hypervisor, and the 'superpages' domain config option
that can be specified when creating a new domain via xend/xm.
 -- Keir
On 21/03/2011 21:01, "Keshav Darak" <keshav_darak@xxxxxxxxx> wrote:
> have corrected few mistakes in previously attached xen patch file.
> Please review it.
> 
> --- On Sun, 3/20/11, Keshav Darak <keshav_darak@xxxxxxxxx> wrote:
>> 
>> From: Keshav Darak <keshav_darak@xxxxxxxxx>
>> Subject: [Xen-devel] PATCH: Hugepage support for Domains booting with 4KB
>> pages
>> To: xen-devel@xxxxxxxxxxxxxxxxxxx
>> Cc: jeremy@xxxxxxxx, keir@xxxxxxx
>> Date: Sunday, March 20, 2011, 10:34 PM
>> 
>> 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 listhead of this list is
>> inside the domain structure with name "hugepage_list". When the domain is
>> booting, at that time the memory seen by the kernel is allocated memory  less
>> the amount required for hugepages. The function reserve_hugepage_range is
>> called as a initcall. Before this function the xen_extra_mem_start points to
>> this apparent end of the memory. In this function we reserve the PFN range
>> for the hugepages which are going to be allocated by kernel by incrementing
>> the xen_extra_mem_start. We maintain these PFNs as pages in
>> "xen_hugepfn_list" in the kernel.
>> 
>> Now before the kernel requests for hugepages, it makes a hypercall
>> HYPERVISOR_memory_op  to get count of hugepages allocated to it and
>> accordingly reserves the pfn range.
>> then whenever kernel requests for hugepages it again make hypercall
>> HYPERVISOR_memory_op to get the preallocated hugepage and according makes the
>> p2m mapping on both sides (xen as well as kernel side)
>> 
>> The approach can be better explained using the presentation attached.
>> 
>> --
>> Keshav Darak
>> Kaustubh Kabra
>> Ashwin Vasani 
>> Aditya Gadre
>> 
>>  
>> 
>> -----Inline Attachment Follows-----
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx </mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx>
>> http://lists.xensource.com/xen-devel
> 
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
 | 
 |  | 
  
    |  |  |