On Thu, Dec 01, 2011 at 06:40:31PM +0100, Peter Zijlstra wrote: > On Wed, 2011-11-23 at 16:03 +0100, Andrea Arcangeli wrote: <snip> > >From what I gather what you propose is to periodically unmap all user > memory (or map it !r !w !x, which is effectively the same) and take the > fault. This fault will establish a thread:page relation. One can just > use that or involve some history as well. Once you have this thread:page > relation set you want to group them on the same node. > > There's various problems with that, firstly of course the overhead, > storing this thread:page relation set requires quite a lot of memory. > Secondly I'm not quite sure I see how that works for threads that share > a working set. Suppose you have 4 threads and 2 working sets, how do you > make sure to keep the 2 groups together. I don't think that's evident > from the simple thread:page relation data [*]. Thirdly I immensely > dislike all these background scanner things, they make it very hard to > account time to those who actually use it. Picture yourself as the administrator of a virtualized host, with a given workload of guests doing their tasks. All it takes is to understand from a high level what the algorithms of ksm (collapsing of equal content-pages into same physical RAM) and khugepaged (collapsing of 4k pages in 2MB pages, good for TLB) are doing (and that should be documented), and infer from that what is happening. The same is valid for the guy who is writing management tools and exposing the statistics to the system administrator. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
