Skip to contentSkip to conversation

the trouble with large pages

DISCUSSION Hollis Blanchard 4 participants 5 messages Sep 7, 2007 1 message not in the archive KVM

lore
Share & tools
lore
#0 lore raw

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.

Signature · 9 lines
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/
#1 lore raw
Quoted 9 lines · 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?

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...

Quoted 8 lines

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/

#2 lore raw
In reply to Hollis Blanchard
Quoted 7 lines

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/

A message that is not in the archive (sent off-list or not yet received): cbb4e3dae13d87254c87d7d6746e4403-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org

#4 lore raw
Quoted 4 lines · Segher Boessenkool
Quoted 3 lines

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.

Quoted 8 lines
Quoted 3 lines

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

Quoted 12 lines

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 [email protected]
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/

#5 lore raw
In reply to Hollis Blanchard
Quoted 9 lines · 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?

Quoted 6 lines

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/