All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH 06 of 11] libxl: introduce libxl_get_numainfo()
Date: Thu, 31 May 2012 16:57:26 +0200	[thread overview]
Message-ID: <1338476246.15014.41.camel@Solace> (raw)
In-Reply-To: <20423.32435.342657.764548@mariner.uk.xensource.com>


[-- Attachment #1.1: Type: text/plain, Size: 3214 bytes --]

On Thu, 2012-05-31 at 15:22 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH 06 of 11] libxl: introduce libxl_get_numainfo()"):
> > Make some NUMA node information available to the toolstack. Achieve
> > this by means of xc_numainfo(), which exposes memory size and amount
> > of free memory of each node, as well as the relative distances of
> > each node to all the others.
> ...
> > +#define LIBXL_NUMAINFO_INVALID_ENTRY (~(uint32_t)0)
> 
> Is there some reason we can't just make sure we use the same value for
> this in both places ?  That would avoid the need for this:
> 
Sorry, with "both places" being? Maybe you're talking about reusing
LIBXL_CPUTOPOLOGY_INVALID_ENTRY here as well? If yes, I think it is
possible and I also thought doing it like that... Or was it something
different you were saying?

> > +#define V(mem, i) (mem[i] == INVALID_NUMAINFO_ID) ? \
> > +    LIBXL_NUMAINFO_INVALID_ENTRY : mem[i]
> 
> I appreciate that the types aren't the same.  In libxc it's an
> unsigned long.  But shouldn't they be the same ?
> 
I again am not sure about what types you are talking about here I'm
afraid... :-(

> > +libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr)
> > +{
> > +    xc_numainfo_t ninfo;
> > +    DECLARE_HYPERCALL_BUFFER(xc_node_to_memsize_t, memsize);
> > +    DECLARE_HYPERCALL_BUFFER(xc_node_to_memfree_t, memfree);
> > +    DECLARE_HYPERCALL_BUFFER(uint32_t, node_distances);
> > +    libxl_numainfo *ret = NULL;
> > +    int i, j, max_nodes;
> > +
> > +    max_nodes = libxl_get_max_nodes(ctx);
> > +    if (max_nodes == 0)
> > +    {
> > +        LIBXL__LOG(ctx, XTL_ERROR, "Unable to determine number of NODES");
> > +        return NULL;
> > +    }
> > +
> > +    memsize = xc_hypercall_buffer_alloc
> > +        (ctx->xch, memsize, sizeof(*memsize) * max_nodes);
> > +    memfree = xc_hypercall_buffer_alloc
> > +        (ctx->xch, memfree, sizeof(*memfree) * max_nodes);
> > +    node_distances = xc_hypercall_buffer_alloc
> > +        (ctx->xch, node_distances, sizeof(*node_distances) * max_nodes * max_nodes);
> 
> This kind of stuff normally lives in libxc.  I appreciate that we have
> a bit of it in libxl already, but do we want to perpetuate that ?
> 
Yes, I did this like it is mainly because it is exactly what
libxl_get_cpu_topology() does and thus I thought it to be the way to
go. :-)

> > +    ret = malloc(sizeof(libxl_numainfo) * max_nodes);
> > +    if (ret == NULL) {
> 
> In libxl you can use libxl__zalloc(NULL,...) (and don't have to check
> for errors because it can't fail).  But perhaps this is going into
> libxc ?
> 
About libxl__zalloc(), noted. Thanks.

About moving this all, I can of couse look into doing that, if wanted.

> I'd like to hear what other people say about putting this in libxl
> vs. libxc.
>
Sure, just let me know what people prefer...

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

  reply	other threads:[~2012-05-31 14:57 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-31 12:11 [PATCH 00 of 11] Automatic NUMA placement for xl Dario Faggioli
2012-05-31 12:11 ` [PATCH 01 of 11] libxc: abstract xenctl_cpumap to just xenctl_map Dario Faggioli
2012-05-31 14:10   ` Ian Jackson
2012-05-31 14:47     ` George Dunlap
2012-05-31 14:55       ` George Dunlap
2012-05-31 15:01   ` George Dunlap
2012-05-31 15:08     ` Dario Faggioli
2012-05-31 12:11 ` [PATCH 02 of 11] libxl: abstract libxl_cpumap to just libxl_map Dario Faggioli
2012-05-31 14:11   ` Ian Jackson
2012-05-31 14:54   ` George Dunlap
2012-05-31 12:11 ` [PATCH 03 of 11] libxc, libxl: introduce xc_nodemap_t and libxl_nodemap Dario Faggioli
2012-05-31 14:12   ` Ian Jackson
2012-05-31 14:32     ` Dario Faggioli
2012-05-31 15:41   ` George Dunlap
2012-05-31 16:09     ` Dario Faggioli
2012-05-31 12:11 ` [PATCH 04 of 11] libxl: expand the libxl_{cpu, node}map API a bit Dario Faggioli
2012-05-31 14:13   ` Ian Jackson
2012-05-31 14:30     ` Dario Faggioli
2012-06-08 13:54       ` Ian Jackson
2012-05-31 15:51   ` George Dunlap
2012-05-31 16:01     ` Dario Faggioli
2012-05-31 12:11 ` [PATCH 05 of 11] libxl: add a new Array type to the IDL Dario Faggioli
2012-05-31 15:54   ` George Dunlap
2012-06-08 14:03   ` Ian Jackson
2012-06-08 15:14     ` Dario Faggioli
2012-06-08 15:17       ` Ian Jackson
2012-06-08 15:37       ` Ian Jackson
2012-06-08 15:52         ` Dario Faggioli
2012-06-08 15:57           ` Ian Jackson
2012-06-12  9:02       ` Ian Campbell
2012-06-13  6:59         ` Dario Faggioli
2012-06-18 12:06           ` Dario Faggioli
2012-06-21 14:32           ` Dario Faggioli
2012-06-21 14:35             ` Ian Campbell
2012-06-21 14:35           ` Dario Faggioli
2012-06-26 16:28   ` Ian Jackson
2012-06-26 16:30     ` Ian Campbell
2012-06-26 16:58       ` Dario Faggioli
2012-05-31 12:11 ` [PATCH 06 of 11] libxl: introduce libxl_get_numainfo() Dario Faggioli
2012-05-31 14:22   ` Ian Jackson
2012-05-31 14:57     ` Dario Faggioli [this message]
2012-06-01 16:44     ` George Dunlap
2012-06-01 16:58       ` Ian Jackson
2012-05-31 12:11 ` [PATCH 07 of 11] xen: enhance dump_numa output Dario Faggioli
2012-05-31 14:23   ` Ian Jackson
2012-05-31 14:35     ` Dario Faggioli
2012-05-31 12:11 ` [PATCH 08 of 11] xl: add more NUMA information to `xl info -n' Dario Faggioli
2012-05-31 14:24   ` Ian Jackson
2012-05-31 14:40     ` Dario Faggioli
2012-06-01 16:56     ` George Dunlap
2012-05-31 12:11 ` [PATCH 09 of 11] libxl, xl: enable automatic placement of guests on NUMA nodes Dario Faggioli
2012-05-31 15:02   ` Ian Jackson
2012-05-31 16:27     ` Dario Faggioli
2012-05-31 16:42       ` Ian Campbell
2012-05-31 16:56         ` Dario Faggioli
2012-05-31 12:11 ` [PATCH 10 of 11] libxl, xl: heuristics for reordering NUMA placement candidates Dario Faggioli
2012-05-31 12:11 ` [PATCH 11 of 11] Some automatic NUMA placement documentation Dario Faggioli
2012-05-31 15:08   ` Ian Jackson
2012-05-31 15:41     ` Dario Faggioli
2012-06-08 14:01       ` Ian Jackson
2012-06-08 14:03         ` George Dunlap
2012-06-08 14:06           ` Ian Jackson
2012-06-08 14:35             ` Dario Faggioli
2012-06-08 15:19         ` Dario Faggioli

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=1338476246.15014.41.camel@Solace \
    --to=raistlin@linux.it \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=Stefano.Stabellini@eu.citrix.com \
    --cc=andre.przywara@amd.com \
    --cc=juergen.gross@ts.fujitsu.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.