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
next prev parent 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.