From: Ryan Harper <ryanh@us.ibm.com>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>,
Ryan Harper <ryanh@us.ibm.com>,
xen-devel@lists.xensource.com, Ryan Grimm <grimm@us.ibm.com>
Subject: Re: [PATCH 2/3] xend: Add multiple cpumasks support
Date: Tue, 15 Aug 2006 17:58:37 -0500 [thread overview]
Message-ID: <20060815225837.GU1694@us.ibm.com> (raw)
In-Reply-To: <C1074D77.E40%Keir.Fraser@cl.cam.ac.uk>
* Keir Fraser <Keir.Fraser@cl.cam.ac.uk> [2006-08-15 17:36]:
>
>
>
> On 14/8/06 11:20 pm, "Ryan Harper" <ryanh@us.ibm.com> wrote:
>
> >> Either Keir's cpu[X] = "Y" approach or my cpu = [ "A","B","C" ] approach
> >> seem workable.
> >>
> >> Keir's approach is rather ill defined if someone tries using both cpu=
> >> and cpu[X]= in the same config file, but I don't see that as a big
> >> problem. Take your pick :-)
> >
> > I'm leaning toward the list notation since I already have code that
> > parses that properly.
>
> Am I mistaken or aren't both the above forms basically the same (in both
> cases 'cpu' is a list of strings)? I like this form, even if we cook it down
> in xm into a different sxp syntax (if you want to avoid python lists in the
> sxp).
I'm not really opposed to any particular way. IMO, I think that having a
single config variable, cpus, is simpler, and more compact, for
instance, when passing a one-time value on the command line. Certainly
cpu[X]="Y" is easier to understand, but I don't think it is a far
stretch to list form.
If we went with cpu[X]="Y", would we do away with cpus? If not, would
a cpus value map to cpu[0]? And what about 'cpu', which currently is
prepended to the cpus value, which retains the behavior of pinning
VCPU0?
I'm about to resend the patches which currently parse the list form,
[ "a", "b", "c" ]. If you are set on cpu[X]="Y" and we know how we want
to handled the cases I mentioned above, I can rework to suit. My
preference is the list form which has the benefit of working code
behind it.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
ryanh@us.ibm.com
next prev parent reply other threads:[~2006-08-15 22:58 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-14 22:03 [PATCH 2/3] xend: Add multiple cpumasks support Ian Pratt
2006-08-14 22:20 ` Ryan Harper
2006-08-15 9:07 ` Keir Fraser
2006-08-15 22:58 ` Ryan Harper [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-08-17 2:01 Ian Pratt
2006-08-17 15:27 ` Ryan Grimm
2006-08-15 23:26 Ian Pratt
2006-08-16 11:15 ` Subrahmanian, Raj
2006-08-14 22:40 Ian Pratt
2006-08-14 22:46 ` Ryan Harper
2006-08-16 23:34 ` Ryan Grimm
2006-08-14 18:55 Ian Pratt
2006-08-14 19:08 ` Ryan Harper
2006-08-14 20:15 ` Ryan Harper
2006-08-14 18:10 Ian Pratt
2006-08-14 18:47 ` Ryan Harper
2006-08-15 8:44 ` Keir Fraser
2006-08-15 23:01 ` Ryan Harper
2006-08-14 16:57 Ryan Harper
2006-08-14 17:37 ` Keir Fraser
2006-08-14 17:48 ` Ryan Harper
2006-08-14 17:55 ` Keir Fraser
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=20060815225837.GU1694@us.ibm.com \
--to=ryanh@us.ibm.com \
--cc=Keir.Fraser@cl.cam.ac.uk \
--cc=grimm@us.ibm.com \
--cc=m+Ian.Pratt@cl.cam.ac.uk \
--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.