<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 4, 2015 at 8:06 PM, Okky Hendriansyah <span dir="ltr"><<a href="mailto:okky@nostratech.com" target="_blank">okky@nostratech.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><div style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">On November 5, 2015 at 09:49:27, Alex Williamson (<a href="mailto:alex.l.williamson@gmail.com" target="_blank">alex.l.williamson@gmail.com</a>) wrote:</div><div><blockquote type="cite" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span><div></div><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"></div></blockquote><div>I don't buy that hugepages allocated at boot perform any different than hugepages allocated dynamically.</div></div></div></div></div></span></blockquote></div></span><p>I stand corrected. So that means memory fragmentation on the host has no practical performance hit on using hugepages for device assignment? </p></div></blockquote><div><br></div><div>The fragmentation issue with hugepages is generally that as memory gets fragmented, there's no guarantee that you can reliably allocate hugepages.  A script that doesn't do any error checking to test how many huge pages are actually available might work 99% of the time, but the 100th time you start that guest without a host system reboot, maybe it won't get all the pages you requested and starting the VM will fail.  That's the more significant benefit of boot time allocated hugepages I think, but you also lose the flexibility of having that memory available for general use otherwise, which is why transparent hugepages are so nice, but as I already mentioned, those don't work with page pinning for device assignment.</div><div><br></div><div>I can imagine that contiguous hugepages has some tiny benefit for TLB hits and prefetching, but I also expect it would be well within the noise of anything other than a very targeted benchmark.</div><div><br></div><div>AMD-Vi does actually have quite robust superpage support in the IOMMU, so on those platforms the IOTLB might see a benefit from being able to map 4MB, 8MB, 16MB, etc contiguous memory ranges, but it's probably still very difficult to measure.  It also only seems to work reliably on the FX systems since many APU users need to disable this feature for stability.</div></div></div></div>