All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@amd.com>
To: Dulloor <dulloor@gmail.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [vNUMA v2][PATCH 1/8] Config options
Date: Tue, 3 Aug 2010 23:28:31 +0200	[thread overview]
Message-ID: <4C5889FF.1040500@amd.com> (raw)
In-Reply-To: <AANLkTimj-Q0T8EMJzkY=+T1sA=gFE6t50DiDfAsnJCW6@mail.gmail.com>

Dulloor wrote:
> On Tue, Aug 3, 2010 at 5:40 AM, Andre Przywara <andre.przywara@amd.com> wrote:
>> Dulloor wrote:
>>> Implement the following config options :
>>>
>>> strategy = "str", where str is confine/stripe/split/auto
>>> vnodes = <num-nodes>
>>> stripesz = <size-in-pages>
>> As Ian already said, I'd also prefer NUMA related names instead of
>> the generic "strategy". Also "vnodes" may be a bit misleading, what about
>> "guestnodes"?
> That's right. How about "numa_strategy", "numa_vnodes", and "numa_stripesz" ?
The numa_vnodes looks quite cumbersome and isn't very intuitive in 
understanding. I'd prefer numa_guestnodes (although this is a bit long) 
cause it is clear in what it means. But I can also live with numa_vnodes 
if this is put in the example config file together with an appropriate 
comment.
> 
>>> +typedef struct xc_domain_numa_config
>>> +{
>>> +    uint32_t strategy;      /* By default, DONTCARE (for now) */
>>> +    uint32_t nr_nodes;      /* For SPLIT/STRIPE */
>>> +    uint32_t stripe_size;   /* For STRIPE only */
>> Are 32 bit here sufficient? Although for the stripe size probably 4GB
>> are more than needed, I'd prefer to use 64bit (or long) for each
>> memory-related variable.
> Here, stripe_size is in 4K pages, so effectively we have 44 bits,
> which should suffice.
> But, for consistency, I will change that to 64-bit.
Thanks. I think we all should have learned from the "640 KB is enough" 
story ;-)
> 
>>> +} xc_domain_numa_config_t;
>>> +
>>> +++ b/tools/libxl/xl_cmdimpl.c
>>> +static uint32_t numa_str_to_val(const char *str)
>>> +{
>>> +    if (!strcasecmp(str, "AUTO"))
>>> +        return XC_DOM_NUMA_AUTO;
>>> +    if (!strcasecmp(str, "CONFINE"))
>>> +        return XC_DOM_NUMA_CONFINE;
>>> +    if (!strcasecmp(str, "SPLIT"))
>>> +        return XC_DOM_NUMA_SPLIT;
>>> +    if (!strcasecmp(str, "STRIPE"))
>>> +        return XC_DOM_NUMA_STRIPE;
>>> +
>>> +    return XC_DOM_NUMA_NONE;
>> Shouldn't the function return something like "unknown" here?
>> This would allow to detect typos in the config file.
> I  was thinking that if someone misconfigures (or for typos), we fall back
> to the current case. But, it makes sense not to do that. Will change this.
I was already seeing the mails on xen-devel asking why 
numa_strategy=strip doesn't make a difference ;-) If we have only a few 
possible strategies, we should fail on illegal ones. That would also 
make later extension easier to use, as they fail on older setups and the 
user gets a hint on this.

Regards,
Andre.


-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448-3567-12

  reply	other threads:[~2010-08-03 21:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1BEA8649F0C00540AB2811D7922ECB6C9338B4CB@orsmsx507.amr.corp.intel.com>
2010-07-02 23:53 ` [XEN][vNUMA][PATCH 2/9] Config options Dulloor
2010-08-01 22:01   ` [vNUMA v2][PATCH 1/8] " Dulloor
2010-08-03  6:11     ` Ian Campbell
2010-08-03 12:40     ` Andre Przywara
2010-08-03 15:18       ` Dulloor
2010-08-03 21:28         ` Andre Przywara [this message]
2010-08-16 16:19     ` Andre Przywara
2010-08-16 16:47       ` Dulloor

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=4C5889FF.1040500@amd.com \
    --to=andre.przywara@amd.com \
    --cc=dulloor@gmail.com \
    --cc=xen-devel@lists.xensource.com \
    /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.