From: Chao Peng <chao.p.peng@linux.intel.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: keir@xen.org, Ian.Campbell@citrix.com,
stefano.stabellini@eu.citrix.com, George.Dunlap@eu.citrix.com,
andrew.cooper3@citrix.com, Ian.Jackson@eu.citrix.com,
xen-devel@lists.xen.org, JBeulich@suse.com,
dgdegra@tycho.nsa.gov
Subject: Re: [PATCH v20 10/10] tools: CMDs and APIs for Cache Monitoring Technology
Date: Mon, 6 Oct 2014 21:32:53 +0800 [thread overview]
Message-ID: <20141006133253.GA25440@pengc-linux> (raw)
In-Reply-To: <20141003124956.GB7627@zion.uk.xensource.com>
On Fri, Oct 03, 2014 at 01:49:56PM +0100, Wei Liu wrote:
> Thanks for this quick turnaround.
>
> Overall this looks good to me. Just some more questions on one thing I
> don't understand.
>
> On Fri, Oct 03, 2014 at 07:55:15PM +0800, Chao Peng wrote:
> [...]
> > +int libxl__pick_random_socket_cpu(libxl__gc *gc, uint32_t socketid)
> > +{
>
> This name is clearer.
>
> But still, why randomization is required?
>
> Does this mean picking arbitrary CPU returns the same result to library
> user? If so, why randomization is required?
The background here is that the L3 cache info we want to get in this
patch serial is a per-socket resource. To get it, we need to run the
related RDMSR from a cpu in that socket. So our real purpose of this
routine is to pick up a cpu number in that socket. From function
perspective, any cpu in that socket should work.
But for different domains we may have more than one
getting-l3-cache-info operations for a certain socket. We want to avoid
to run all these operations always on a same cpu every time. So the
randomization is used for load-balance among all the cpus in the same
socket.
>
> > + int i, j, cpu, nr_cpus;
> > + libxl_cputopology *topology;
> > + int *socket_cpus;
> > +
> > + topology = libxl_get_cpu_topology(CTX, &nr_cpus);
> > + if (!topology)
> > + return ERROR_FAIL;
> > +
> > + socket_cpus = libxl__malloc(gc, sizeof(int) * nr_cpus);
> > +
> > + for (i = 0, j = 0; i < nr_cpus; i++)
> > + if (topology[i].socket == socketid)
> > + socket_cpus[j++] = i;
> > +
> > + /* load balance among cpus in the same socket. */
> > + cpu = socket_cpus[rand() % j];
> > +
>
> There is one bug I can see. If socketid is not a valid id, j is not
> incremented. Then here you will have "divided by 0" error.
>
> Although this is internal function, I don't see any sanity check in the
> public function that calls into this helper. In some instances it's even
> the first helper function that gets called.
>
> My suggestion is that you make sure j is not 0 before dividing; return
> ERROR_INVAL otherwise.
Good catch, thanks Wei.
Will fix in next version.
Chao
>
>
> > + libxl_cputopology_list_free(topology, nr_cpus);
>
> (of course, don't forget to call this in error path as well)
>
> Wei.
>
> > + return cpu;
> > +}
> > +
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2014-10-06 13:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-03 11:55 [PATCH v20 00/10] enable Cache Monitoring Technology (CMT) feature Chao Peng
2014-10-03 11:55 ` [PATCH v20 01/10] x86: add generic resource (e.g. MSR) access hypercall Chao Peng
2014-10-03 11:55 ` [PATCH v20 02/10] xsm: add resource operation related xsm policy Chao Peng
2014-10-03 11:55 ` [PATCH v20 03/10] tools: provide interface for generic resource access Chao Peng
2014-10-03 11:55 ` [PATCH v20 04/10] x86: detect and initialize Cache Monitoring Technology feature Chao Peng
2014-10-03 11:55 ` [PATCH v20 05/10] x86: dynamically attach/detach CMT service for a guest Chao Peng
2014-10-03 11:55 ` [PATCH v20 06/10] x86: collect global CMT information Chao Peng
2014-10-03 11:55 ` [PATCH v20 07/10] x86: enable CMT for each domain RMID Chao Peng
2014-10-03 11:55 ` [PATCH v20 08/10] x86: add CMT related MSRs in allowed list Chao Peng
2014-10-03 11:55 ` [PATCH v20 09/10] xsm: add CMT related xsm policies Chao Peng
2014-10-03 11:55 ` [PATCH v20 10/10] tools: CMDs and APIs for Cache Monitoring Technology Chao Peng
2014-10-03 12:49 ` Wei Liu
2014-10-06 13:32 ` Chao Peng [this message]
2014-10-06 13:55 ` Wei Liu
2014-10-06 14:18 ` Chao Peng
2014-10-06 14:24 ` Wei Liu
2014-10-06 14:27 ` Andrew Cooper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141006133253.GA25440@pengc-linux \
--to=chao.p.peng@linux.intel.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=keir@xen.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.