All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Gorm Hansen <jacobg@diku.dk>
To: "Neugebauer, Rolf" <rolf.neugebauer@intel.com>
Cc: Kip Macy <kmacy@fsmware.com>, Xen-devel@lists.sourceforge.net
Subject: Re: Xen as a kernel module
Date: Tue, 25 Jan 2005 19:12:15 -0800	[thread overview]
Message-ID: <41F70A8F.9030200@diku.dk> (raw)
In-Reply-To: <39CC97884CA19A4D8D6296FE94357BCB0161A804@swsmsx404>

Neugebauer, Rolf wrote:

> However, I think it would be foolish to remove the ability to run
> separate driver domains from Xen as it doesn't seem to add significant
> overhead (over running them in Dom0) and it has the potential of being
> extremely useful. You already mentioned the shipping of device drivers,
> there might also some interesting security applications. We can
> currently already provide some degree of isolation against device driver
> bugs and for the DMA issue there are a number of known and existing
> solutions (see eg the L4 OSDI device driver paper). The grant-table
> design (unfortunately not fully implemented yet) with some form of
> IO-MMU should provide the rest of the isolation.

First of all, my suggestion was to have this as a configuration option, 
or even a separate implementation, providing just the ability to host 
domUs. I am sure this is doable, as it seems to be what coLinux is doing 
with some success. I was not suggestion throwing away existing 
functionality, but to optimize for the common case, i.e. a single Linux 
providing all drivers.

Secondly, there have been repeated reports on this list of people having 
problems with lower performance in domU than in dom0, perhaps due to 
cheap hardware, perhaps just due to misconfiguration, and the figures on 
the Xen website have not been updated to reflect what the actual 
situation is, so I guess nobody knows what the overhead will look like 
for a specific type of application. I would worry about MPI-style jobs, 
where you need both low latency and high bandwidth networking, and where 
you are likely to fully utilize the TLBs as well. I cannot see how 
performance does not get hurt in this situation, when Xen needs to flush 
the TLB for every interrupt, or alternatively needs to bundle 
interrupts, thus increasing latency.

Jacob


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

  reply	other threads:[~2005-01-26  3:12 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-26  2:34 Xen as a kernel module Neugebauer, Rolf
2005-01-26  3:12 ` Jacob Gorm Hansen [this message]
2005-01-26  7:55   ` Keir Fraser
2005-01-27 13:24   ` Mark Williamson
2005-01-28 20:59     ` Ronald G. Minnich
2005-01-28 23:16       ` Jacob Gorm Hansen
2005-01-28 23:26         ` Ronald G. Minnich
2005-01-28 23:29           ` Jacob Gorm Hansen
2005-01-29  2:15           ` Adam Sulmicki
2005-01-26  3:57 ` Ronald G. Minnich
  -- strict thread matches above, loose matches on Subject: below --
2005-01-26 11:41 Ian Pratt
2005-01-26  1:24 Jacob Gorm Hansen
2005-01-26  1:32 ` Kip Macy
2005-01-26  1:59   ` Jacob Gorm Hansen
2005-01-26  4:30 ` Ronald G. Minnich
2005-01-26  8:41 ` Steven Hand
2005-01-26 23:19   ` Jacob Gorm Hansen
2005-01-27 15:05     ` Tobias Hunger
2005-01-28 18:32       ` Mark Williamson
2005-01-28 20:09       ` Jacob Gorm Hansen
2005-01-27 13:30   ` Mark Williamson

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=41F70A8F.9030200@diku.dk \
    --to=jacobg@diku.dk \
    --cc=Xen-devel@lists.sourceforge.net \
    --cc=kmacy@fsmware.com \
    --cc=rolf.neugebauer@intel.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.