Re: additional domain.c memory allocation causes "xm create" to fail

From: misiu godfrey <godfrey@cs.queensu.ca>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: additional domain.c memory allocation causes "xm create" to fail
Date: Tue, 4 Sep 2012 16:53:20 -0400	[thread overview]
Message-ID: <CAMVU=QgrX+n5gHuP+a5UzM1MbYJBv2b5BFJbLLhDwOL+8zgnog@mail.gmail.com> (raw)
In-Reply-To: <5046606E.9080908@citrix.com>

[-- Attachment #1.1: Type: text/plain, Size: 1847 bytes --]

> "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

[-- Attachment #1.2: Type: text/html, Size: 2237 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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