From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chao Peng Subject: Re: [PATCH v3 8/8] tools: add tools support for Intel CAT Date: Tue, 7 Apr 2015 16:57:40 +0800 Message-ID: <20150407085740.GE3404@pengc-linux.bj.intel.com> References: <1427373505-9303-1-git-send-email-chao.p.peng@linux.intel.com> <1427373505-9303-9-git-send-email-chao.p.peng@linux.intel.com> <1427819334.2115.194.camel@citrix.com> <20150401075549.GA2696@pengc-linux.bj.intel.com> <1427877666.2115.221.camel@citrix.com> <20150401090642.GB2696@pengc-linux.bj.intel.com> <1427880181.2115.244.camel@citrix.com> <20150402031553.GA3404@pengc-linux.bj.intel.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: <20150402031553.GA3404@pengc-linux.bj.intel.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: Ian Campbell Cc: keir@xen.org, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org, will.auld@intel.com, JBeulich@suse.com, wei.liu2@citrix.com, dgdegra@tycho.nsa.gov List-Id: xen-devel@lists.xenproject.org On Thu, Apr 02, 2015 at 11:15:53AM +0800, Chao Peng wrote: > On Wed, Apr 01, 2015 at 10:23:01AM +0100, Ian Campbell wrote: > > On Wed, 2015-04-01 at 17:06 +0800, Chao Peng wrote: > > > > > If this one returns all sockets but not a specified socket data (which I agreed) > > > > > and not consider legacy cmt code, then I think I can make > > > > > libxl_count_physical_sockets() private and move it to libxl/libxl_psr.c. > > > > > > > > What is the legacy cmt code? But otherwise I agree, yes. > > > > > > In libxl/xl_cmdimpl.c, psr_cmt_show also calculates the socket count > > > itself. If we want to refactor it with new libxl_count_physical_sockets > > > then libxl_count_physical_sockets should be public, otherwise it can be > > > private to libxl_psr.c only. From my side, both directions sound OK. > > > > Ah, so we would want a "return a list of all sockets" variant of > > libxl_psr_cmt_get_cache_occupancy too? I think that's fine, we need to > > keep the old interface but we could easily add a new one, e.g. > > libxl_psr_cmt_get_all_cache_occupancy (insert the word "sockets" if you > > like). > > The libxl_psr_cmt_get_cache_occupancy is actually not used in xl anymore > and should be considered as obsolete. Substitute is > libxl_psr_cmt_get_sample which is the common API for both cache > occupancy and memory bandwidth(For the latter the routine will be called > twice). So if we really want to do everything batch in libxl then > perhaps we should do that for libxl_psr_cmt_get_sample. > > The other candidate is libxl_psr_cmt_get_l3_cache_size, which can also > do batch in libxl. > > While there is also drawback: If both > libxl_psr_cmt_get_sample/libxl_psr_cmt_get_l3_cache_size do their > batches in libxl, then libxl_count_physical_sockets will be called twice > in libxl which may bring performance drop. > > Another solution is only do batch for libxl_psr_cmt_get_l3_cache_size. > It returns all sockets's cache size and meantime the socket number. Once > we get socket number, other functions(Both libxl_psr_cmt_get_sample for > CMT/MBM and libxl_psr_cat_get_l3_info/libxl_psr_cat_get_cbm for CAT) > can be called socket by socket in xl. Ian, does this solution sounds OK to you? Chao > > > > So both interfaces would be something like: > > int libxl_psr_....(ctx, domid, TYPE **list_r, int *nr); > > > > And on success *list_r points to a newly allocated array and *nr is the > > number of elements in that array. TYPE depends on which op it is, so for > > cache_occupancy it seems a uint32_t. > > > > Is the socket address space always contiguous and starting at zero? If > > not then the array might need to contain (socket,TYPE) structs. > > > > Ian. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel