All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: George Dunlap <dunlapg@umich.edu>
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	xen-devel@lists.xensource.com,
	Keir Fraser <keir.fraser@eu.citrix.com>
Subject: Re: Cpu pools discussion
Date: Tue, 28 Jul 2009 08:41:17 +0800	[thread overview]
Message-ID: <4A6E492D.201@oracle.com> (raw)
In-Reply-To: <de76405a0907270820gd76458cs34354a61cc410acb@mail.gmail.com>

George Dunlap wrote:
> Keir (and community),
> 
> Any thoughts on Jeurgen Gross' patch on cpu pools?
> 
> As a reminder, the idea is to allow "pools" of cpus that would have
> separate schedulers.  Physical cpus and domains can be moved from one
> pool to another only by an explicit command.  The main purpose Fujitsu
> seems to have is to allow a simple machine "partitioning" that is more
> robust than using simple affinity masks.  Another potential advantage
> would be the ability to use different schedulers for different
> purposes.
> 
> For my part, it seems like they should be OK.  The main thing I don't
> like is the ugliness related to continue_hypercall_on_cpu(), described
> below.
> 
> Jeurgen, could you remind us what were the advantages of pools in the
> hypervisor, versus just having
> affinity masks (with maybe sugar in the toolstack)?
> 
> Re the ugly part of the patch, relating to continue_hypercall_on_cpu():
> 
> Domains are assigned to a pool, so
> if continue_hypercall_on_cpu() is called for a cpu not in the domain's
> pool, you can't just run it normally.  Jeurgen's solution (IIRC) was to
> pause all domains in the other pool, temporarily move the cpu in
> question to the calling domain's pool, finish the hypercall, then move
> the cpu in question back to the other pool.
> 
> Since there's a lot of antecedents in that, let's take an example:
> 
> Two pools; Pool A has cpus 0 and 1, pool B has cpus 2 and 3.
> 
> Domain 0 is running in pool A, domain 1 is running in pool B.
> 
> Domain 0 calls "continue_hypercall_on_cpu()" for cpu 2.
> 
> Cpu 2 is in pool B, so Jeurgen's patch:
>  * Pauses domain 1
>  * Moves cpu 2 to pool A
>  * Finishes the hypercall
>  * Moves cpu 2 back to pool B
>  * Unpauses domain 1
> 
> That seemed a bit ugly to me, but I'm not familiar enough with the use
> cases or the code to know if there's a cleaner solution.
> 
A usecase from me: I want a pool that passthrough pcpus to the mission critical domains. A scheduling algorithm
will map vcpus to pcpus one by one in this pool. That will implement a reliable hard partitioning.
although it will lose some benefit of virtualization.

And we still want a pool using the credit scheduler for common domains.

thanks,

zhigang

>  -George
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

  parent reply	other threads:[~2009-07-28  0:41 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-27 15:20 Cpu pools discussion George Dunlap
2009-07-27 15:50 ` Keir Fraser
2009-07-28  0:41 ` Zhigang Wang [this message]
2009-07-28  9:19   ` Tim Deegan
2009-07-28 10:15     ` Juergen Gross
2009-07-28 12:50       ` George Dunlap
2009-07-28 13:07         ` Tim Deegan
2009-07-28 13:24           ` Juergen Gross
2009-07-28 13:31             ` Tim Deegan
2009-07-28 13:39               ` Juergen Gross
2009-07-28 13:47                 ` George Dunlap
2009-07-28 13:57                   ` Juergen Gross
2009-07-28 15:29                     ` Dan Magenheimer
2009-07-28 15:49                       ` Keir Fraser
2009-07-28 16:26                         ` George Dunlap
2009-07-29  0:29                         ` Zhigang Wang
2009-07-29  5:47                       ` Juergen Gross
2009-07-28 13:41               ` George Dunlap
2009-07-28 13:55                 ` Keir Fraser
2009-07-29  6:14                   ` Juergen Gross
2009-07-29  7:39                     ` Keir Fraser
2009-07-29  8:52                       ` Juergen Gross
2009-07-29  9:35                         ` Keir Fraser
2009-07-29 11:06                           ` Juergen Gross
2009-07-29 12:28                             ` Keir Fraser
2009-07-29 12:33                               ` Juergen Gross
2009-07-29 13:00                                 ` Keir Fraser
2009-07-30  5:46                                   ` Juergen Gross
2009-07-30  8:30                                     ` Keir Fraser
2009-07-30  8:58                                       ` Juergen Gross
2009-07-30 12:51                                       ` Juergen Gross
2009-07-30 13:18                                         ` Keir Fraser
2009-07-31  5:25                                           ` Juergen Gross
2009-07-28  5:40 ` Juergen Gross
2009-07-28  9:09   ` Keir Fraser
2009-07-28 10:19     ` Juergen Gross

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=4A6E492D.201@oracle.com \
    --to=zhigang.x.wang@oracle.com \
    --cc=dunlapg@umich.edu \
    --cc=juergen.gross@ts.fujitsu.com \
    --cc=keir.fraser@eu.citrix.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.