With base on comments and feedback on LLC handling from Daniel Vetter, Chris Wilson and Ben Widawsky, I reworked my patch into a more useful approach for detecting presence of different cache levels from userspace. So, in this context, PATCH 1 adds the very same .has_llc flag and debugfs entry for it. PATCH 2 does the initial job of preparing to export cache levels to userspace, which can be queried via the DRM interface by means of PATCH 3. And finally, PATCH 4 allows to get and set a specific cache level for each bo. The i915_gem_object_set_cache_level() routine does a good job of checking whether the objects should be put into specific cache levels already. When thinking about possible optimizations and tweaks for different cache levels, this is what we thought: - The most usual case is for I915_MADV_WILLNEED object, where we can change its cache level as we want. - If we are trying to change cache level of I915_MADV_DONTNEED object, on first glance, it is pointless to do so. However, it could make sense for some sort of prefetching or quick change of mind (we certainly can mark an object as DONTNEED and get to reallocate and WILLNEED it again). So why not? - If we are trying to change cache level of a PURGED object, nothing will happen, as it has no GTT space anyway. One possible optimization would be to remove an object from LLC on gem_madvise_ioctl(..I915_MADV_DONTNEED). However, I don't think it is worth the extra cycles - at some point, it will be removed eventually anyway, even if we leave it at LLC. So those are all the possible cases I could think of. Of course, I could have missed something, so just yell if so :).
