From: Keir Fraser <keir.xen@gmail.com>
To: Keshav Darak <keshav_darak@yahoo.com>, xen-devel@lists.xensource.com
Cc: jeremy@goop.org
Subject: Re: PATCH: Hugepage support for Domains booting with 4KB pages
Date: Tue, 22 Mar 2011 14:07:23 +0000 [thread overview]
Message-ID: <C9AE5D9B.153D1%keir.xen@gmail.com> (raw)
In-Reply-To: <205767.82133.qm@web59601.mail.ac4.yahoo.com>
On 22/03/2011 12:36, "Keshav Darak" <keshav_darak@yahoo.com> wrote:
> Keir,
> We are aware of it and we have to use 'opt_allow_superpages' boolean flag
> in our implementation too. But when we use superpages flag in domain
> configuration file,
> entire domain boots on hugepages (superpages).If the specified memory in
> 'hugepages' for the domain is not available, then the domain does not boot.
> But in our implementation , we target to give only those many hugepages (
> using "hugepage_num" option in config file) to the domain that it actually
> requires and hence entire domain need not be booted on hugepages.
> This is to support domains that boot with 4 KB pages and still can use
> hugepages. So,
> the pressure on the number of hugepages required for a domain even to boot is
> reduced to a great extent.
Okay, I don't see why that would need further changes in the hypervisor
itself, however.
-- Keir
> --- On Mon, 3/21/11, Keir Fraser <keir.xen@gmail.com> wrote:
>>
>> From: Keir Fraser <keir.xen@gmail.com>
>> Subject: Re: [Xen-devel] PATCH: Hugepage support for Domains booting with 4KB
>> pages
>> To: "Keshav Darak" <keshav_darak@yahoo.com>, xen-devel@lists.xensource.com
>> Cc: jeremy@goop.org
>> Date: Monday, March 21, 2011, 9:31 PM
>>
>> 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@yahoo.com
>> </mc/compose?to=keshav_darak@yahoo.com> > wrote:
>>
>>> have corrected few mistakes in previously attached xen patch file.
>>> Please review it.
>>>
>>> --- On Sun, 3/20/11, Keshav Darak <keshav_darak@yahoo.com
>>> </mc/compose?to=keshav_darak@yahoo.com> > wrote:
>>>>
>>>> From: Keshav Darak <keshav_darak@yahoo.com
>>>> </mc/compose?to=keshav_darak@yahoo.com> >
>>>> Subject: [Xen-devel] PATCH: Hugepage support for Domains booting with 4KB
>>>> pages
>>>> To: xen-devel@lists.xensource.com
>>>> </mc/compose?to=xen-devel@lists.xensource.com>
>>>> Cc: jeremy@goop.org </mc/compose?to=jeremy@goop.org> , keir@xen.org
>>>> </mc/compose?to=keir@xen.org>
>>>> 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@lists.xensource.com
>>>> </mc/compose?to=Xen-devel@lists.xensource.com>
>>>> </mc/compose?to=Xen-devel@lists.xensource.com
>>>> </mc/compose?to=Xen-devel@lists.xensource.com> >
>>>> http://lists.xensource.com/xen-devel
>>>
>>>
>>
>>
>
>
next prev parent reply other threads:[~2011-03-22 14:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-21 21:01 PATCH: Hugepage support for Domains booting with 4KB pages Keshav Darak
2011-03-21 21:31 ` Keir Fraser
2011-03-22 12:36 ` Keshav Darak
2011-03-22 14:07 ` Keir Fraser [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-03-22 18:05 Keshav Darak
2011-03-20 22:34 Keshav Darak
2011-03-22 16:49 ` Konrad Rzeszutek Wilk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C9AE5D9B.153D1%keir.xen@gmail.com \
--to=keir.xen@gmail.com \
--cc=jeremy@goop.org \
--cc=keshav_darak@yahoo.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).