[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] additional domain.c memory allocation causes "xm create" to fail




"flush" is the correct term.

However, the structure of caches work against you.  With a set associative cache, you have no control over which of the sets gets used for your cache line.  So on an N way set associate cache, your worst case may only dirty 1/N of the actual lines in the cache.

After that, your L1 cache inclusion policy is going to affect how you dirty your L2 cache, as well as whether you have joined caches or split instruction and data caches.

Furthermore, on newer processes, multiple cores may share an L2 or L3 cache, and context switches are unlike to occur at exactly the same time on each core, meaning that a context switch on one core is going to (attempt to) nuke the L2 cache of the VM which is in mid run on another core.  Conversely, even executing the loop trying to dirty the cache will mean that you dont get all of it, and having another core executing on the same L2 cache means it will pull its data back during your dirtying loop.

I have some more robust code that takes account of the set-associativity of the cache, code that I originally thought was going to be superfluous in this situation.  Now that I have managed to execute this basic loop I can address a more complex environment with a set-associative.  Currently, I don't need to worry about an L3 cache because my test machine has no shared cache between cores (nothing higher than an L2).  Although I will keep this in mind, as it will need to be addressed once I get beyond the proof of concept.

Anyway, validating the xmalloc return value seems to have addressed my problem, although the log I am printing to seems to imply that xmalloc is never failing.  I'll look further into it once I get more things working.  Thanks a lot for your advice, Andrew.  Sorry my problem ended up being so trivial.

-Misiu

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.