[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v20 10/10] tools: CMDs and APIs for Cache Monitoring Technology
On Mon, Oct 06, 2014 at 10:18:28PM +0800, Chao Peng wrote: > On Mon, Oct 06, 2014 at 02:55:02PM +0100, Wei Liu wrote: > > On Mon, Oct 06, 2014 at 09:32:53PM +0800, Chao Peng wrote: > > > 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. > > > > > > > I'm not sure how much we can get from this randomization. Are you > > implying this operation is quite heavy workload for a cpu and / or > > there's potentially hundreds or thousands of parallel operations > > executed at the same time? FWIW in order to get cpu topology you need to > > issue hypercall, which is quite expensive (perhaps not that expensive > > compared to the CMT operation itself?). > > For CMT itself, I don't think we gain much benifit from this. But we > introduced a new generic resource_op hypercall which can be used for potential > heavy workload in the future. So we add this function in the tools side. If so, I would rather avoid doing pre-mature optimization. We can always add it in later when it's necessary. Wei. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |