view TODO @ 2791:6c9e794798b9

bitkeeper revision 1.1159.143.1 (41851ce0SeaLauOV4DJoO_UxeSbw1Q)

more doc updates...
author smh22@tempest.cl.cam.ac.uk
date Sun Oct 31 17:12:00 2004 +0000 (2004-10-31)
parents 10ffc8273164
line source
1 Future plans and enhancements
2 =============================
4 For up-to-date details of features currently under implementation,
5 visit the Xen project roadmap at:
6 http://www.cl.cam.ac.uk/Research/SRG/netos/xen/roadmap.html
8 IO enhancements
9 ---------------
10 There are also a number of memory management enhancements that didn't
11 make this release: We have plans for a "universal buffer cache" that
12 enables otherwise unused system memory to be used by domains in a
13 read-only fashion.
15 Disk scheduling
16 ---------------
17 The current disk scheduler is rather simplistic (batch round robin),
18 and could be replaced by e.g. Cello if we have QoS isolation
19 problems. For most things it seems to work OK, but there's currently
20 no service differentiation or weighting.
22 Improved load-balancing
23 -----------------------
24 Currently, although Xen runs on SMP and SMT (hyperthreaded) machines,
25 the scheduling is far from smart -- domains are currently statically
26 assigned to a CPU when they are created (in a round robin fashion).
27 We'd like to see a user-space load-balancing daemon that can shift
28 domains between CPUs as their activity changes.
30 Multiprocessor guest VMs
31 ------------------------
32 Xen currently only supports uniprocessor guest OSes. We have designed
33 the Xen interface with MP guests in mind, and plan to build an MP
34 Linux guest in due course. Basically, an MP guest would consist of
35 multiple scheduling domains (one per CPU) sharing a single memory
36 protection domain. The only extra complexity for the Xen VM system is
37 ensuring that when a page transitions from holding a page table or
38 page directory to a write-able page, we must ensure that no other CPU
39 still has the page in its TLB to ensure memory system integrity. One
40 other issue for supporting MP guests is that we'll need some sort of
41 CPU gang scheduler, which will require some research.
43 Cluster management
44 ------------------
45 There have been discussions regarding a unified cluster controller
46 for Xen deployments. This would leverage the existing features of
47 Xen to present a uniform control interface for managing a cluster
48 as a pool of resources, rather than a set of completely distinct
49 machines.
51 64-bit x86
52 ----------
53 Xen can currently use up to 4GB of memory. It's possible for 32-bit
54 x86 machines to address up to 64GB, but it requires using a different
55 page table format that would be rather tedious to support. Our
56 preferred approach is to virtualize 64-bit x86 (x86/64), as supported
57 by modern AMD and Intel processors. The large address space provided
58 by a 64-bit execution model greatly simplifies support for large-memory
59 configurations. Our implementation for x86/64 is in progress and should
60 feature in our next major release.