From mboxrd@z Thu Jan  1 00:00:00 1970
From: misiu godfrey <godfrey@cs.queensu.ca>
Subject: Re: additional domain.c memory allocation causes "xm
 create" to fail
Date: Tue, 4 Sep 2012 16:53:20 -0400
Message-ID: <CAMVU=QgrX+n5gHuP+a5UzM1MbYJBv2b5BFJbLLhDwOL+8zgnog@mail.gmail.com>
References: <CAMVU=QgzjT1daB5_zfoP2amtbvWX3X5XZKE6Bj1eX-tTDY=xSQ@mail.gmail.com>
	<50464954.5030207@citrix.com>
	<CAMVU=QgJG=cNH69-kKdWULzV6n2kRrn=d78n75NKuMM_9VXQ9w@mail.gmail.com>
	<5046606E.9080908@citrix.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7170334805161095836=="
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <5046606E.9080908@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

--===============7170334805161095836==
Content-Type: multipart/alternative; boundary=0016e6da2e7fd7697304c8e672cb

--0016e6da2e7fd7697304c8e672cb
Content-Type: text/plain; charset=ISO-8859-1

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

--0016e6da2e7fd7697304c8e672cb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=
=3D"#FFFFFF" text=3D"#000000">
    &quot;flush&quot; is the correct term.<br>
    <br>
    However, the structure of caches work against you.=A0 With a set
    associative cache, you have no control over which of the sets gets
    used for your cache line.=A0 So on an N way set associate cache, your
    worst case may only dirty 1/N of the actual lines in the cache.<br>
    <br>
    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.<br>
    <br>
    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.=A0 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.</div></blockquote><div><br></div><=
div>I have some more robust code that takes account of the set-associativit=
y of the cache, code that I originally thought was going to be superfluous =
in this situation. =A0Now that I have managed to execute this basic loop I =
can address a more complex environment with a set-associative. =A0Currently=
, I don&#39;t need to worry about an L3 cache because my test machine has n=
o shared cache between cores (nothing higher than an L2). =A0Although I wil=
l keep this in mind, as it will need to be addressed once I get beyond the =
proof of concept.</div>
<div><br></div><div>Anyway, validating the xmalloc return value seems to ha=
ve addressed my problem, although the log I am printing to seems to imply t=
hat xmalloc is never failing. =A0I&#39;ll look further into it once I get m=
ore things working. =A0Thanks a lot for your advice, Andrew. =A0Sorry my pr=
oblem ended up being so trivial.</div>
<div><br></div><div>-Misiu</div><div><br></div></div>

--0016e6da2e7fd7697304c8e672cb--


--===============7170334805161095836==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============7170334805161095836==--