Hi Anthony
We are almost on the same page.
>From: Isaku Yamahata [mailto:yamahata@xxxxxxxxxxxxx]
>Sent: 2006年9月29日 13:59
>To: Xu, Anthony
>Cc: Magnus Damm; xen-ia64-devel@xxxxxxxxxxxxxxxxxxx; Tristan Gingold
>Subject: Re: [Xen-ia64-devel][PATCH][RFC] Task: support huge page RE:
>[Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#11460
>
>>
>> As for allocation failure, the first step is, if allocation fails, creating
>> domain fails,
>> The next step is to defragmentation.
>
>For the first step, it sounds reasonable to not care about allocation
>failure.
>I think that page fragmentation should be addressed as a eventual goal.
>It might have an impact on its design.
Agree!
>>
>> I'm using rhel4-u2 as guest, by default, rhel4-u2 set rr4.ps=256M.
>>
>> For latest kernel who supports hugetlbfs, the biggest page size is 4G.
>>
>> The goals from me is supporting 256M, if we can do that, and then supporting
>> huger tlb
>like 1G or 4G is trivial. :-)
>
>I wanted to say that a implementation for hugetlbfs may be different
>from a implementation for large page to map kernel.
>So we should describe not only page-size, but also its purpose.
>I re-summarize the goals. What do you think?
>
>- Support 16MB large page size to map kernel area.
> Although Linux can be configured to use 64MB page size to map kernel,
> we won't support 64MB page size. (at least for first prototype)
> It would be nice to support both kernel mapping page size, 16MB and 64MB,
> but it might be addressed by second phase.
> A domain uses only one of them. Potentially different domains may use
> different kernel mapping page size.
> e.g. domainA uses 16MB to map kernel, domainB uses 64MB to map kernel.
>
>- Support hugetlbfs with 256MB page size.
> If possible, it would be nice to support 1GB page size or 4GB page size.
> The huge page size is determined by Linux boot time options and
> only single page size from 256MB, 1GB, 4GB is used by hugetlbfs of a domain.
> Potentially different domains may use different huge page size.
> e.g. domainA uses 256MB huge page size, domainB uses 1GB huge page size.
> For first prototype, it is reasonable to support only 256MB huge page size.
>
>- page fragmentation should be addressed.
> This isn't addressed at the first step.
> When large contiguous page allocation fails, fall back path is executed
> with normal page size, 16KB, possibly at degraded performance.
> Or try a sort of defragmentation to create a large contiguous memory.
How does XEN support 16MB and 256M in the same domain?
For HVM side, there is no choice; XEN must allocate 256M contiguous memory
chunks for HVM domain.
For DomU side, above method works, and there may be other methods, such as huge
page pools, these methods require cooperation from XEN and DomU.
So the first step is,
Allocate 256M contiguous memory chunks for DomU and HVM domain.
The optimization for domU is the second step.
If contiguous page allocation fails, fall back to normal page size, it's good
choice for the first prototype, So we need a variable to record this domain's
contiguous memory size. Many operations depend on this variable, such as
writing to rr, VHPT operation.
Yes, we will support 1G, 4G,
Currently the largest tlb size IA64 can support is 4G, and they may become
larger.
Per IA64 spec, the guaranteed largest insertable tlb size is 256M, OS can query
insertable tlb sizes from PAL, XEN can capture this operation, and return to OS
the largest insertable tlb size 256M, in this way OS will not use 1G or 4G tlb
size.
What I say is for the first prototype 256M is enough.
So seems there are not so many things need to do for the first prototype.
1. Allocate 256M for domain.
2. Modify VHPT to support huge page.
3. Modify VBD/VNIF to use copy instead of flip.
I can't wait to see how much performance XEN/IA64 can get from supporting huge
page.
BTW is there any bench march on IA64 using huge page?
Thanks,
Anthony
>
>
>--
>yamahata
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home