<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">I learned this recently, having gained access to newer Intel processors: these CPUs (Sandybridge, Haswell) use a form of indexing into the LLC which is no longer direct (i.e. taking specific bits from a physical address to determine which set the cache line in the LLC it goes into), but rather what they call "complex indexing"[1]. Presumably this is some proprietary hashing.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">I wanted to ask -- does page coloring, using direct indexing logic by the kernel, have an advantage if such hashing is used, also if we are unaware of the specific algorithm used to index the LLC? If we are unable to determine which pages will conflict in the cache without careful study, and assuming this algorithm may change between microarchitectures, it seems there may be less benefit to applying the technique.</div><div class="gmail_quote"><br></div><div class="gmail_quote">[1] <span style="font-family:Calibri,sans-serif;font-size:11pt"> </span><span style="font-family:Calibri,sans-serif;font-size:11pt">Intel
Manual Vol.2A Table 3-17, cpuid command 04H</span></div><div class="gmail_quote"><span style="font-family:Calibri,sans-serif;font-size:11pt"><br></span></div><div class="gmail_quote"><font face="Calibri, sans-serif"><span style="font-size:14.6666669845581px">-Alex</span></font></div><div class="gmail_quote"><br></div><div class="gmail_quote">On Tue, Apr 14, 2015 at 10:47 AM, Matthew Dillon <span dir="ltr"><<a href="mailto:dillon@backplane.com" target="_blank">dillon@backplane.com</a>></span> wrote:<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 dir="ltr"><div>--<br><br></div><div>If I recall, FreeBSD mostly removed page coloring from their VM page allocation subsystem.  DragonFly kept it and integrated it into the fine-grained-locked VM page allocator.  There's no advantage to manipulating the parameters for two reasons.<br><br></div><div>First, all page coloring really does is try to avoid degenerate situations in the cpu caches.  The cpu caches are already 4-way or 8-way set-associative.  The page coloring improves this but frankly even the set associativeness in the base cpu caches gets us most of the way there.  So adjusting the page coloring algorithms will not yield any improvements.<br><br></div><div>Secondly, the L1 cache is a physical memory cache but it is also virtually indexed.  This is a cpu hardware optimization that allows the cache lookup to be initiated concurrent with the TLB lookup.  Because of this, physical set associatively does not actually solve all the problems which can occur with a virtually indexed cache.<br><br></div><div>So the userland memory allocator implements an offsetting feature for allocations which attempts to address the virtually indexed cache issues.  This feature is just as important as the physical page coloring feature for performance purposes.<br></div><div><br></div>-Matt<br><div><br></div></div><div class=""><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 14, 2015 at 10:10 AM, Alex Merritt <span dir="ltr"><<a href="mailto:merritt.alex@gmail.com" target="_blank">merritt.alex@gmail.com</a>></span> wrote:<br><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 dir="ltr">Hello!<div><br></div><div>I am interested in learning whether Dragonfly supports large pages (2M and 1G), and secondly, what mechanisms exist for applications to have influence over the colors used to assign the physical pages backing their memory, specifically for private anonymous mmap'd regions. Regarding coloring, I'd like to be able to evaluate applications with a small number of colors (restricting their access to the last-level cache) and compare their performance to more/all colors available. I am initially looking to work in hacks to achieve this to perform some preliminary experiments, perhaps by way of a kernel module or something.</div><div><br></div><div>A cursory search of the code showed no hints at support for large pages, but I did find there are more internal functions governing the allocation of pages based on colors, compared to FreeBSD (10.1). In FreeBSD it seems colors are only considered for regions which are added that are backed by a file, but I am not 100% certain.</div><div><br></div><div>I appreciate any help!</div><div><br></div><div>Thanks,</div><div>Alex</div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>