All of lore.kernel.org
 help / color / mirror / Atom feed
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
>>> 
>>> 
>> 
>> 
> 
> 

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.