All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bin Ren <bin.ren@gmail.com>
To: John L Griffin <jlg@us.ibm.com>
Cc: xen-devel@lists.sourceforge.net
Subject: Re: Multiple priviliged domains
Date: Sun, 19 Dec 2004 17:05:08 +0000	[thread overview]
Message-ID: <8ae7802504121909056239a209@mail.gmail.com> (raw)
In-Reply-To: <OFED209BE8.61BE3DC0-ON85256F6F.0017749D-85256F6F.00204FF3@us.ibm.com>

On Sun, 19 Dec 2004 00:52:54 -0500, John L Griffin <jlg@us.ibm.com> wrote:

> 1. What is the model for allocating processor time to Domain-0?  Based on
> my read of the Xen docs to date, I would expect it to [at least be
> intended to] have an unbounded priority share of the total processing
> resources, with some attempt at allocating unprivileged-domain-specific
> processing (e.g., handling I/O or memory allocation requests) to the
> requesting unprivileged domain.  Along these lines, should there be a
> parameterizable configuration file for Domain-0?

Current schedulers in Xen don't treat Dom0 differently. In current
model, Dom0 plays two major roles: provides a control console for
user-interaction; provides I/O handling for other domains. These two
roles have different or even conflicting scheduling requirement: the
former is response time; the latter is I/O throughput and latency.
Ideally, we should put the two parts in two privileged domains and let
the scheduler treat them differently. This leads to your next question
about multiple privileged domains.

> 2. Have there been discussions about allowing multiple simultaneous
> privileged domains, among which the physical resources are split?  Or
> perhaps "semiprivileged" domains -- for example, a domain that handles all
> the I/O requests to a particular storage device, or alternatively handles
> all the I/O requests for a particular class/subset of unprivileged
> domains?  I envision a desire for a master control partition (with
> priority resource allocation) that forms the root of a hierarchical domain
> structure, under which one or more I/O partitions execute.  (I recall
> reading about this sort of design in one of the older VMM papers, or
> perhaps a recent Denali paper?)

I agree that multiple privleged domains make resource management both
conceptually and structurally clearer. So far, very vey few people
actually do that, for several reasons:
(1) It requires non-trivial changes to Xend, which people either don't
bother to hack or can't.
(2) With multiple privileged domains, the domain context switch
overhead can seriously decrease performance. It makes little sense on
current uni- or dual-processors.
(3) Managing multiple privilged domains is surely less easy than
managing one big Dom0.

Surprisingly enough, it's my phd topic at cambridge to do all above.
I've offloaded the entire tcp/ip stack to a privilged domain that's
shared by all others. My next step is to introduce the Makefile
changes, Xend changes to support multiple privilged domains (i.e. put
Xend, NIC device drivers, disk device drivers, tcp/ip stack in
different privileged domains). Then I'll investigate how to schedule
all the domains on multi-core chips. Mark Williamson has experiences
in putting NIC and disk device drivers into privliged domains. I'll
consult him when questions arise.

- Bin


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

  parent reply	other threads:[~2004-12-19 17:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-19  5:52 Multiple priviliged domains John L Griffin
2004-12-19  9:22 ` Ian Pratt
2004-12-19 14:02   ` Jan Kundrát
2004-12-19 17:05 ` Bin Ren [this message]
2004-12-19 18:25 ` Mark Williamson
2004-12-19 11:52   ` Jacob Gorm Hansen
  -- strict thread matches above, loose matches on Subject: below --
2004-12-19 21:44 Neugebauer, Rolf
2004-12-19 14:52 ` Jacob Gorm Hansen
2004-12-19 22:29 ` Ian Pratt

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=8ae7802504121909056239a209@mail.gmail.com \
    --to=bin.ren@gmail.com \
    --cc=br260@cam.ac.uk \
    --cc=jlg@us.ibm.com \
    --cc=xen-devel@lists.sourceforge.net \
    /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.