<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 7, 2018 at 10:26 PM David Greene <<a href="mailto:dag@cray.com">dag@cray.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Andrea Di Biagio <<a href="mailto:andrea.dibiagio@gmail.com" target="_blank">andrea.dibiagio@gmail.com</a>> writes:<br>
<br>
> Hi David,<br>
<br>
Hi Andrea!<br>
<br>
> I like your idea of providing a framework to describe the cache<br>
> hierarchy/prefetchers etc.<br>
> I can definitely think of a couple of ways to reuse that bit of<br>
> information in llvm-mca.<br>
<br>
Great! I was hoping it would be useful for that.<br>
<br>
> I have a few questions about the general design.<br>
<br>
Thank you so much for your feedback.<br>
<br>
> It looks like in your model, you don't describe whether a cache is<br>
> inclusive or exclusive. I am not sure if that is useful for the<br>
> algorithms that you have in mind. However, in some processors, the LLC<br>
> (last level cache) is exclusive, and doesn't include lines from the<br>
> lower levels. You could potentially have a mix of inclusive/exclusive<br>
> shared/private caches; you may want to model those aspects.<br>
<br>
Yes, I can see for simulation purposes that would be useful. It's not<br>
so useful in the compiler cache optimizations I have in mind because<br>
everything is a heuristic anyway and details like inclusivity are<br>
basically noise.<br>
<br>
I would certainly be possible to add an inclusive/exclusive property on<br>
a cache level. I think that having the property implicitly reference<br>
the next level up would make sense (e.g. L3 is inclusive of L2 or L2 is<br>
exclusive of L1). Then if, say, L3 is inclusive of L2 and L2 is<br>
inclusive of L1, one could by transitivity reason that L3 is inclusive<br>
of L1. What do you think?<br></blockquote><div><br></div><div>That would be nice to have. Thanks.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> When you mention "write combining", you do that in the context of<br>
> streaming buffers used by nontemporal operations.<br>
> On x86, a write combining buffer allows temporal adjacent stores to be<br>
> combined together. Those stores would bypass the cache, and committed<br>
> together as a single store transaction. Write combining may fail for a<br>
> number of reasons; for example: there may be alignment/size<br>
> requirements; stores are not allowed to overlap; etc. Describing all<br>
> those constraints could be problematic (and maybe outside of the scope<br>
> of what you want to do). I guess, it is unclear at this stage (at<br>
> least to me) how much information is required in practice.<br>
<br>
So far what I've outlined is what we've found to be sufficient for the<br>
compiler optimizations we have, but again, for simulator modeling much<br>
more would be desired. On the X86, only memory mapped as WC<br>
(write-combining) in the MTRRs actually uses the buffers, in addition to<br>
NT stores to WB (write-back) memory. I believe most user memory is<br>
mapped WB so general stores won't use the write-combining buffers.<br>
There's an ordering issue with using write-combining and it wouldn't be<br>
safe to use it in general code without being very careful and inserting<br>
lots of fences.<br></blockquote><div><br></div><div><br></div><div>Yeah. Mine was just a curiosity; the term "write combining" is kind of overloaded. Depending on the context it assumes a different meaning.</div><div>I don't think it is a problem if write combining memory is outside of the scope of this work.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Modeling the use of MTRRs to represent different types of memory is out<br>
of scope for this proposal but could be added later, I think.<br>
<br>
The key thing I'm trying to model with the stream/write-combining<br>
buffers is the limited buffer resources to handle streams of NT<br>
operations. These same resources would be used for WC-typed memory so<br>
they could apply to more than NT operations. That could be imporant for<br>
compilers that deal with code that wants to heavily use write-combining<br>
(like manipulating video output, for example).<br>
<br>
> Ideally, it would be nice to have the concept of "memory type", and<br>
> map memory types to resources/memory consistency models. Not sure if<br>
> there is already a way to do that mapping, nor if it would improve<br>
> your existing framework. In theory, you could add the ability to<br>
> describe constraints/resources for memory types, and then have users<br>
> define how memory operations map to different types. That information<br>
> would then drive the algorithm/cost model that computes resource<br>
> allocation/schedule. However, I may be thinking too much about<br>
> possible use cases ;-).<br>
<br>
Yeah, that would be nice for a number of use cases. That level of<br>
detail is beyond the scope of the current work but it's an interesting<br>
idea and I'll certainly keep it in mind as I work through this.<br>
<br>
> That being said, I like having extra information to feed to the<br>
> compiler (and llvm-mca :-)). Let see what other people think about it.<br>
<br>
So far it looks like positive responses with questions around API naming<br>
and such. I haven't heard anything show-stopping yet. Hopefully I'll<br>
get a chance to start posting patches soon.<br>
<br></blockquote><div><br></div><div>I look forward to see your patches soon.<br></div><div><br> </div><div>Cheers,</div><div>Andrea</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-David<br>
</blockquote></div></div>