All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] 0/2 VCPU creation and allocation
@ 2005-10-10 15:16 Ryan Harper
  2005-10-10 15:29 ` Keir Fraser
  0 siblings, 1 reply; 14+ messages in thread
From: Ryan Harper @ 2005-10-10 15:16 UTC (permalink / raw)
  To: xen-devel

I've put together two patches.  The first introduces a new dom0_op,
set_max_vcpus, which with an associated variable and a check in the
VCPUOP handler fixes [1]bug 288.  Also included is a new VCPUOP, 
VCPUOP_create, which handles all of the vcpu creation tasks and leaves
initialization and unpausing to VCPUOP_initialize.  The separation
allows for build-time allocation of vcpus which becomes more important
when trying to allocate memory in a NUMA-aware manner (i.e. knowing
which physical cpus are being used in a domain before we allocate the
memory).

The second patch adds a new domain allocmap cpumap_t which is a bitmap
of physical cpus from which vcpus are to be allocated.  As vcpus are
created, the selection of which physical cpu is balanced across the set
of physical cpus within the map.  The patch lets us control vcpu
allocation at a high level (start all VCPUS on hyperthreads, NODE1,
CPU2).

1. http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=288

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh@us.ibm.com

^ permalink raw reply	[flat|nested] 14+ messages in thread
* RE: [PATCH] 0/2 VCPU creation and allocation
@ 2005-10-10 15:31 Ian Pratt
  0 siblings, 0 replies; 14+ messages in thread
From: Ian Pratt @ 2005-10-10 15:31 UTC (permalink / raw)
  To: Keir Fraser, Ryan Harper; +Cc: xen-devel, ewan

> > Also included is a new VCPUOP,
> > VCPUOP_create, which handles all of the vcpu creation tasks 
> and leaves 
> > initialization and unpausing to VCPUOP_initialize.
> 
> I think two new Xen operations is one too many.
> 
> Either we should take set_max_vcpus, and have that implicitly 
> do the work of VCPUOP_create, or we should take VCPUOP_create 
> (callable only by domain0) and have that implicitly increase 
> max_vcpus for the subject domain.

While we're at it, let's clean up the xm commands too. I tihnk its
pointless letting the user specify the vcpu they want to enable/disable.
Let's change the command names to vcpu-add / vcpu-remove and have them
work on the lowest numbered free vcpu in the case of vcpu-add and the
highest currently active in the case of vcpu-remove.

 
Ian

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2005-10-12 16:15 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-10-10 15:16 [PATCH] 0/2 VCPU creation and allocation Ryan Harper
2005-10-10 15:29 ` Keir Fraser
2005-10-10 15:28   ` Ryan Harper
2005-10-10 16:01     ` Keir Fraser
2005-10-10 16:05       ` Ryan Harper
2005-10-10 16:17         ` Keir Fraser
2005-10-10 16:23           ` Ryan Harper
2005-10-10 16:39             ` Keir Fraser
2005-10-11 15:13               ` [PATCH] 2nd try: " Ryan Harper
2005-10-11 15:15               ` [PATCH] 2nd try: 1/2 " Ryan Harper
2005-10-11 15:16               ` [PATCH] 2nd try: 2/2 " Ryan Harper
2005-10-12 16:10                 ` Keir Fraser
2005-10-12 16:15                   ` Ryan Harper
  -- strict thread matches above, loose matches on Subject: below --
2005-10-10 15:31 [PATCH] 0/2 " Ian Pratt

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.