the trouble with large pages

the trouble with large pages

[Hollis Blanchard]

The PowerPC 440 Linux kernel uses 256MB pages for the linear mapping.
When we run that as a guest, those pages would of course need to be
physically contiguous in the host.

I think long-term the KVM plan is to move memory allocation out of the
kernel (where it currently uses vmalloc) into userspace, with the idea
being that userspace could allocate memory via hugetlbfs. Anybody tried
hugetlbfs on 440 or e500?

A poor-man's equivalent might be to limit the host memory to e.g. 256MB,
then have userspace mmap(/dev/ram) starting there.

Another possibility is to fake out guest large pages by actually using
small pages on the host, and handle the extra faults in KVM without
notifying the guest.

-- 
Hollis Blanchard
IBM Linux Technology Center


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: the trouble with large pages

[Izik Eidus]

Hollis Blanchard wrote:
> The PowerPC 440 Linux kernel uses 256MB pages for the linear mapping.
> When we run that as a guest, those pages would of course need to be
> physically contiguous in the host.
>
> I think long-term the KVM plan is to move memory allocation out of the
> kernel (where it currently uses vmalloc) into userspace, with the idea
> being that userspace could allocate memory via hugetlbfs. Anybody tried
> hugetlbfs on 440 or e500?
>   
there is already kvm patch that move the memory allocation to userspace 
you can check it out.
it will be merged to kvm as soon as some swapping issues will be address...
> A poor-man's equivalent might be to limit the host memory to e.g. 256MB,
> then have userspace mmap(/dev/ram) starting there.
>
> Another possibility is to fake out guest large pages by actually using
> small pages on the host, and handle the extra faults in KVM without
> notifying the guest.
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: the trouble with large pages

[Segher Boessenkool]

> The PowerPC 440 Linux kernel uses 256MB pages for the linear mapping.
> When we run that as a guest, those pages would of course need to be
> physically contiguous in the host.

> Another possibility is to fake out guest large pages by actually using
> small pages on the host, and handle the extra faults in KVM without
> notifying the guest.

That seems like the best plan, for a first shot anyway.  Also,
even when you do support backing 256MB pages with 256MB pages,
you probably still want the small-page backing as a backup in
case you run out of large pages.


Segher


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: the trouble with large pages

[Anthony Liguori]

On Fri, 2007-09-07 at 17:00 +0200, Segher Boessenkool wrote:
> > The PowerPC 440 Linux kernel uses 256MB pages for the linear mapping.
> > When we run that as a guest, those pages would of course need to be
> > physically contiguous in the host.
> 
> > Another possibility is to fake out guest large pages by actually using
> > small pages on the host, and handle the extra faults in KVM without
> > notifying the guest.
> 
> That seems like the best plan, for a first shot anyway.  Also,
> even when you do support backing 256MB pages with 256MB pages,
> you probably still want the small-page backing as a backup in
> case you run out of large pages.

If you want to be able support things like migration, it's alsa
important to be able to demote large pages to smaller ones so that you
can do finer granularity dirty tracking.

Regards,

Anthony Liguori

> Segher
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: the trouble with large pages

[Anthony Liguori]

On Fri, 2007-09-07 at 09:40 -0500, Hollis Blanchard wrote:
> The PowerPC 440 Linux kernel uses 256MB pages for the linear mapping.
> When we run that as a guest, those pages would of course need to be
> physically contiguous in the host.
> 
> I think long-term the KVM plan is to move memory allocation out of the
> kernel (where it currently uses vmalloc) into userspace, with the idea
> being that userspace could allocate memory via hugetlbfs. Anybody tried
> hugetlbfs on 440 or e500?
> 
> A poor-man's equivalent might be to limit the host memory to e.g. 256MB,
> then have userspace mmap(/dev/ram) starting there.
> 
> Another possibility is to fake out guest large pages by actually using
> small pages on the host, and handle the extra faults in KVM without
> notifying the guest.

This is what is done on x86.

Regards,

Anthony Liguori



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/