| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
 Re: [Xen-devel] PATCH: Hugepage support for Domains booting with 4KB	pages
 
To: xen-devel@xxxxxxxxxxxxxxxxxxxFrom: Keshav Darak <keshav_darak@xxxxxxxxx>Date: Mon, 21 Mar 2011 14:01:51 -0700 (PDT)Cc: jeremy@xxxxxxxx, keir@xxxxxxxDelivery-date: Mon, 21 Mar 2011 14:02:48 -0700Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;	h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type;	b=tXdujlpRykHoRptztKE4J6c8QPTpwmBkikEbgJTw51K2+0MF6C0buVPFJUPXkhqFiDgQUiWEz7KSErB1xEUHr4YfySdxB6DfG+DKvSL4udCF88AaTP2ydQe6goK2noo2yLGcL3JQezSkWDmRiGI4qBnJv7URz9/r8GljY9Yw/S8=;List-id: Xen developer discussion <xen-devel.lists.xensource.com> 
 | 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-----
 
 
 | 
 
 Attachment:
xen.patchDescription: Text Data
 _______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
 
 |