From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chao Peng Subject: Re: [PATCH v20 10/10] tools: CMDs and APIs for Cache Monitoring Technology Date: Mon, 6 Oct 2014 21:32:53 +0800 Message-ID: <20141006133253.GA25440@pengc-linux> References: <1412337315-15609-1-git-send-email-chao.p.peng@linux.intel.com> <1412337315-15609-11-git-send-email-chao.p.peng@linux.intel.com> <20141003124956.GB7627@zion.uk.xensource.com> Reply-To: Chao Peng Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20141003124956.GB7627@zion.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu 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 List-Id: xen-devel@lists.xenproject.org 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