2nd IEEE International Conference on Cloud Computing Technology and Science

A Mechanism of Flexible Memory Exchange in

Cloud Computing Environments
Graduate

Takeshi Okuda, Eiji Kawai and Suguru Yamaguchi

School of Information Science, Nara Institute of Science and Technology, Nara, Japan 6300192
e-mail: okuda@is.naist.jp
National Institute of Information and Communications Technology
e-mail: eiji-ka@nict.go.jp

AbstractIn cloud computing environment, virtual machine

technology is used as a means of flexibly assigning workloads to
real machines based on the workloads static profiles. Though this
technology aims at flexible and dynamic resource sharing, memory is underutilized in cloud environments. We propose a virtual
swap management mechanism (VSMM) that enables flexible and
dynamic memory sharing via a local area network. The VSMM
can virtualize swap devices seen by a guest operating system
(OS), and transparently switch underlying physical devices to
that OS. In this paper, we explain the VSMM architecture and
provide details on our prototype implementation using the Xen
open source hypervisor, open source iSCSI implementations, and
logical volume management. Through various experiments, we
demonstrate that VSMM can contribute to improving process
performance and maximally utilizing the equipped memory in
cloud environments.

in degraded performance, because a local HDD used for a

swap device is quite slow compared to physical memory.
Taking as examples applications such as salary calculation
and sales statistics that are to be built in cloud environments,
data grow as time progresses, and will exceed the amount of
memory assigned to the VM. When there is unused memory
in a VM cluster and a guest OS needs more memory, that OS
will be aided by having unused memory made available to it,
and at the same time increase memory usage.
Various remote memory sharing studies show that using
remote memory across machines improves performance. Many
of these make remote memory available to a machine as a
remote swap. The problem remaining here is that this lacks a
dynamic remote memory allocation mechanism to effectively
utilize memory in a cluster. To solve this problem, we propose
a virtual swap management mechanism that improves performance and increases memory usage. This mechanism virtualizes swap devices and provides a basic mechanism for flexible
and dynamic memory exchange in a cloud environment.
In this paper, we propose a mechanism of virtual swap
management in cloud computing environments. In the next
section, we analyze the memory utilization problem in a cloud
environment and extract requirements for the solution. Then
we propose the virtual swap management mechanism that
fulfills these requirements. After that, we explain the design
detail of the prototype system based on the proposal. Finally,
we demonstrate the effectiveness of the proposed mechanism
through experiments using this prototype system.

I. I NTRODUCTION
Numerous applications and services are transitioning from
running on a single PC into running on a cloud platform.
Cloud platforms basically consist of a virtual machine (VM)
cluster and APIs to manage the cluster. VM clusters are used
to consolidate various servers into fewer real servers to benefit
from a statistical multiplexing effect of computing resources.
Because each VM tends to be supplied with enough memory
to process a peak workload, the guest operating system (OS)
always has abundant memory left unused. Unused in this
paper refers to both situations where the memory is assigned
to no VM, and where memory assigned to a certain VM is
not used by the guest OS.
In dynamic memory allocation used in a modern OS, an
internal fragmentation occurs when some part of the allocated
memory is not used. An external fragmentation occurs when
there is insufficient memory left to fulfill the allocation request.
Similarly, from the viewpoint of VM cluster management, an
internal fragmentation occurs when the memory assigned to
a VM is not fully used by the guest OS, and an external
fragmentation occurs when there is insufficient memory to
accommodate more VMs, which are therefore left unassigned.
To further complicate the matter, these fragmentations are
scattered within a VM cluster.
Even if one guest OS needs more memory than what is
assigned to it, it cannot use the memory unused by another
guest OS. In this situation, the guest OS is going short of
physical memory and makes use of a swap device. This results
978-0-7695-4302-4/10 $26.00 2010 IEEE
DOI 10.1109/CloudCom.2010.56

II. P ROBLEM AND R EQUIREMENT A NALYSIS

In general, a VM cluster administrator assigns VMs the
minimum amount of memory to process the peak workload.
While most of the memory is usually left unused by the
guest OS, another guest OS will suffer from performance
degradation when a process running on it needs more memory.
In the case of a memory shortage, the guest OS uses a swap
device that is generally part of the local HDD. An HDD has
poorer performance than local memory in terms of bandwidth
and latency. The existing VM environment lacks the flexibility
of expanding memory beyond the statically assigned value,
even if the guest OS is running short of memory and there is
unused memory in the same real machine. The problem we
want to solve here is that the poor performance of a guest OS
75

requiring more memory, though there is unused memory in

the same real machine or in a VM cluster.
A number of works have addressed enables remote memory
sharing across machines via high-speed networks [1][4], and
these function toward letting real machines virtually house
huge memory space. Most of these works aim at statically
building a remote memory mechanism. This approach lacks a
management mechanism for sharing memory that can assign
remote memory dynamically to a running machine.
For example, take a situation with six VMs and with their
guest OS assigned maximum memory of 512 MB and which
have a 1 GB swap device on a local HDD. These Typically
always have low load and consume less memory, for instance
256 MB. When one of these needs to process about 512 MB of
data for a transaction, the guest OS will use the swap device
on a local HDD to accommodate the entire 512 MB in the
memory space. Though 1,280 MB of memory remains unused
in the VM cluster or in the same real machine, the guest OS
must use a swap device on a local HDD and the process does
not finish within a predictable time. Another example is one
in which real machines having unused memory unassigned
to any VMs. We expect this situation can be relaxed by
managing memory usage and flexibly exchanging unused
memory between real machines and guest OS dynamically.
It will be effective to introduce a cluster-wide flexible
memory exchange mechanism that aggregates unused memory
from guest OS, and shares it dynamically with a guest OS that
is going short of memory. Moreover, these operations must be
performed transparently to the guest OS, since many types of
guest OS are used in cloud environments. It is desirable to
implement this mechanism outside of the guest OS and not to
affect the choice of them.
To make this flexible memory exchange mechanism, we
extracted four functional requirements and one deployment
requirement: 1) a mechanism to detect and gather unused
memory from guest OS, 2) a mechanism to assign the amassed
memory to a guest OS needing more memory and replace the
swap device on a local HDD with that in the remote memory,
3) a mechanism to return the remote swap to providers upon
the memory shortages resolution or in the case of a memory
shortage for the providers, and 4) a swap device replacement
mechanism transparent to the guest OS; along with 5) the
system must use open standard and open source software to
ease the cost of deployment into a cloud environment.

VM is deployed. Li et al. proposed a deployment planning

algorithm that combines a multi-dimensional packing heuristic
and network flow optimization to satisfy simultaneous constraints on memory availability and license availability at a
minimum cost [6]. This algorithm requires a static profile
on the applications regarding how much CPU cycles and
memory needed by the application. While memory usage is
apt to change dynamically, the algorithm does not consider
the run-time usage of memory for each VM. Tang et al.
proposed an application placement algorithm that scales up to
enterprise data centers [7]. Though this algorithm can compute
optimal application placement periodically based on static
information on applications and machines, it cannot take a
dynamic information of memory usage into consideration.
VMware ESX Server has a dynamic memory management
mechanism called ballooning [8]. ESX Server supports overcommitment of memory in order to facilitate a higher degree
of server consolidation than would be possible with simple
static partitioning. Overcommitment means that the total
size configured for all running virtual machines exceeds the
total amount of acual machine memory. The system manages the allocation of memory to VMs automatically based
on configuration parameters and system load. Each virtual
machine is given the illusion of having a fixed amount of
physical memory. The max size is a configuration parameter
that represents the maximum amount of machine memory
it can be allocated. A VM is allocated no memory beyond
the configured max size. Also, when no memory is left
unused on the same real machine, the VM cannot request more
memory, even if the other real machine in a VM cluster has
unused memory.
Another possible solution is migrating the VM to the
other real machine with unused memory. In the example case
explained in the previous section, when there is another real
machine with 1 GB of memory left unused, migrating the
VM to that real machine may help the guest OS. Though it
is possible to migrate the VM to the other real machine with
only 512 MB memory left unused, that migration may not
help the guest OS, because the situation does not change.
The survey of related work clearly indicates that no existent
works enable flexible memory exchange in a VM cluster.
IV. P ROPOSAL OF V IRTUAL S WAP M ANAGEMENT
M ECHANISM
We propose a virtual swap management mechanism
(VSMM) that satisfies the extracted requirements. The VSMM
enables dynamic assignment of a remote swap device to the
running guest OS based on the OSs current information. A
virtual swap means that swap devices are virtualized and a
guest OS does not need to know their real location.
To satisfy the above requirements, we have designed four
modules for VSMM: a Memory Watchdog, Virtual Swap Manager, Memory Exporter, and Memory Importer. Fig. 1 explains
the control flow of lending memory in the VSMM. Step 0: The
Memory Watchdog monitors the memory usage of a guest OS
and periodically reports it to the Virtual Swap Manager, for

III. R ELATED W ORK

We surveyed resource management and allocation methods
for service placement in seeking a usable work for solving
this problem. Chen et al. proposed a resource management
system for VM clusters [5], that provides VM image file management and efficient resource mapping called load-aware
mapping. This Load-Aware Mapping strategy places VMs to
low-loaded machines with a VM image file cache in order to
eliminate the overhead of VM image file replication. Though
this system provides resource mapping to reduce deployment
overhead, it cannot re-map the resource dynamically once the

76

1. I need more
memory

4.

Virtual Swap
Manager

2.

Memory
Watchdog

dom-0

0. I have unused
memory

Logical
Volume

Memory
Watchdog

Requests
Extra
Memory

MemoryWatchdog

dom-U

Memory
Importer
5. Replace swap
from local to remote

Virtual
Swap
Manager

Exchanging memory

Memory
Exporter
3. Ready to export

Monitoring
Memory
Usage
Physical
Extent
on HDD

Direction to
Export
Memory

dom-0

MemoryWatchdog

ramfs

Physical
Volume
on ramfs

Physical
Extent
on iSCSI

VMM

Fig. 1.

VMM
SATA or SAS

Flow of lending remote memory

Physical
Volume
on HDD

instance once every second. A Memory Watchdog may reside

in the guest OS or in the management domain. A Virtual
Swap Manager keeps track of memory usage reported from
Memory Watchdogs in a VM cluster. Step 1: In the case of
a memory shortage, the Memory Watchdog asks the Virtual
Swap Manager for available memory. Step 2: When a sufficient
amount of memory is available, the Virtual Swap Manager
tells the donors Memory Watchdog to make unused memory
ready for export. Step 3: The Memory Exporter makes unused
memory ready to use as a block device for the remote acceptor.
Step 4: The Virtual Swap Manager tells the Memory Watchdog
of the acceptor to import and use the remote swap of the
donor. Step 5: The Memory Importer of the acceptor replaces
the swap device from the local HDD to the remote memory.
In the process of returning the borrowed remote swap, the
VSMM reverses the above steps.
Based on these operations the above requirements 1-3 can
be met. To realize the requirement 4, we employed a Logical
Volume Manager (LVM), for switching the physical block
devices of a swap device transparently to a guest OS.

Fig. 2.

Ethernet
Switching Hub

Overview of prototype implementation of VSMM

implemented in dom-0 to avoid affecting the guest OS. Each

guest OS is assigned a swap device as a virtual block device
that is a part of the logical volume. The VSMM can switch
the physical extent allocated to the logical volume between
the local HDD and iSCSI target based on the decision criteria.
Figure 2 depicts the overview of the prototype implementation
of VSMM. The Memory Watchdog monitors the memory
usage of each dom-U and dom-0, and periodically reports
the aggregated amount of available memory for export to the
Virtual Swap Manager. If some of the dom-U falls below
the free memory threshold, the Memory Watchdog requests
extra memory from the Virtual Swap Manager. The Virtual
Swap Manager searches a candidate exporter, and instructs
it to export a specified amount of memory. The exporting
Memory Watchdog makes unused memory ready to export
and then notifies the Virtual Swap Manager of the URL of the
exported memory. The requesting Memory Watchdog accesses
the returned URL and switches a virtual swap to the remote
memory. The switching is performed within dom-0 and the
guest OS does not notice the change of a virtual swap.

A. Decision Criteria for Memory Usage

A Memory Watchdog needs to know whether the guest
OS is going short of memory. Let M be the total amount
of assigned memory to the guest OS. We use threshold
mth = M, 0 < < 1. If the amount of unused memory
is lower than mth , a Memory Watchdog judges that the guest
OS is going short or already short of memory. If this situation
lasts nhigh times, the Memory Watchdog requests from the
Virtual Swap Manager a remote memory for use as a remote
swap device. If the amount of unused memory is greater than
mth , the Memory Watchdog judges that the guest OS has
abundant unused memory. If this situation lasts nlow times,
the Memory Watchdog reports to the Virtual Swap Manager
that some part of the unused memory is exportable. We think
these mth , nhigh , and nlow should be configurable depending
on the usage of the guest OS.

A. Implementation Detail
Memory Watchdogs reside in dom-0 to escape the thrashing
effect of dom-U and a guest OS. A Memory Watchdog
monitors the memory usage of each dom-U through XenStore
and calculates the amount of exportable memory by summing
up the free memory of each dom-U and dom-0, and deducting
the margin. The Memory Watchdog then reports the amount
of exportable memory to the Virtual Swap Manager at the
specified intervals. The Virtual Swap Manager keeps track of
the exportable memory reported by Memory Watchdogs under
the control of the each dom-0. When a Memory Watchdog
detects that the free memory of a dom-U is lower than m th,
and it lasts n high times, it requests extra memory from the
Virtual Swap Manager. If there are Memory Watchdogs with
larger exportable memory than the requested amount, the Virtual Swap Manager selects the one with the smallest exportable
memory. It then requests the selected Memory Watchdog to
export the specified memory amount. Upon receiving the

V. I MPLEMENTATION AND E VALUATION

We implemented the first prototype system in order to
evaluate the effectiveness of the proposed VSMM. We used
the Xen open source hypervisor for VMM [9], [10], and many
parts of the system use Xen-APIs. All the functionalities are

77

TABLE I
E XPERIMENT S ETUP
Check memory usage of each domain-U

VMM
dom-0
dom-U
iSCSI target
iSCSI initiator
LVM

Report aggregated memory usage

Wait requests for t second
Request for exporting

Free memory >= m_th

Make ramfs

Make iscsi target ready

1GbE switches. All servers had two Quad-Core AMD Opteron

processors and 16 GB of memory. Each real server is installed
with open source Xen hypervisor and hosted three guest OS
configured to have 512 MB of memory and 1 GB of swap
device in a logical volume. We used Linux as both dom-0 and
dom-U. Details of the components we used in the experiments
are summarized in Table I. In the following experiments,
every Memory Watchdog monitors memory usage and reports
exportable memory every second, and we set m th to 10% of
the assigned memory to each VMs and set n high to 5. If a
Memory Watchdog observes the amount of free memory of a
certain guest OS at lower than 10% of the assigned memory
for consecutive 5 seconds, it requests extra memory from a
Virtual Swap Manager. This means the Memory Watchdog
waits at least 5 seconds until it requests extra memory even if
the guest OS is suffering from memory shortage.

Free memory < m_th

count++

Notify URL of iscsi target

Count <= n_high

Count > n_high
Send request for exporting
Make iscsi initiator access the URL
pvmove

importing = true

Fig. 3.

Xen-3.4.1
openSUSE-11.2 64bit
openSUSE-11.2 64bit (PVM)
iSCSI Enterprise Target
Open-iSCSI
LVM2

Activity diagram of Memory Watchdog

C. Verification of the Prototype

To verify the prototype we executed two simple workloads
on a guest OS: sequential write and random write access to
the memory area. Both workloads allocate 512 MB of memory
consisting of 128,000 blocks, and then the sequential access
workload stores 4 KB of data to every block sequentially 10
times. On the other hand, the random access workload stores
4 KB of data on randomly chosen blocks 128,000 times and
repeats it 10 times. During store operations, the guest OS must
access a swap device because there is not enough memory
available. We measured how many store operations can be
made in one second. In both Figs. 4 and 5, (a) is normal
operation that uses the local HDD as a swap device, while (b)
and (c) use a virtual swap on the local iSCSI target and remote
iSCSI target respectively. We observed sudden degradation
from about 10 30 seconds in Figs. 4b, 4c, 5b, and 5c. In
these periods, switching a virtual swap from a local HDD
to an iSCSI target occurred. Because the pvmove command
copies the data on the virtual swap from the local HDD to
the iSCSI target, it results in degradation in such a period.
Once switching finishes, the process can make more than twice
as many operations as the local HDD. We can see that the
workload finishes quicker when using the VSMM than when
using the local HDD as a swap device.
In the case of Figs. 4c and 5c, we examined the network
traffic between a borrower and lender. In Figs. 4d and 5d,
real and broken lines respectively draw the network bandwidth
used to write data to and read data from the virtual swap.
From 10 30 seconds, about 400 Mbps is used to switch
the virtual swap from a local HDD to a remote iSCSI target.

export request, the Memory Watchdog makes an iSCSI file

target on the ramfs that is 1.1 times the requested amount
due to LVM meta-data overhead. The Memory Watchdog then
uses iSCSI target administration commands to make the iSCSI
target available from a remote Memory Watchdog using an
iSCSI protocol. A remote swap should be accessed as a block
device because LVM virtualizes block devices. Technologies
such as a Network Block Device [11] and iSCSI [12] can
provide a block device to a remote machine via networks.
We chose iSCSI for realizing a remote swap device. We
use an open source iSCSI target implementation called iSCSI
Enterprise Target [13]. The Virtual Swap Manager then tells
the requesting Memory Watchdog to use that iSCSI target
as a remote swap device. The requesting Memory Watchdog
uses iSCSI initiator management commands to log in to the
iSCSI target and use it as a block device. We use an open
source iSCSI initiator implementation called Open-iSCSI [14].
To switch a virtual swap from a local HDD to a remote
memory and vice versa, we used the pvcreate, vgextend and
pvmove commands. The pvmove command moves a logical
volume from one physical volume to another. A simple activity
diagram of the Memory Watchdog is depicted in Fig. 3.
B. Experiment Setup
We conducted experiments to verify the prototype and
measure the improvement of system performance achieved by
the VSMM. We used three PC severs to build a small cloud
environment, which ware connected with both 10GbE and

78

50 100

200

300

50

100

150

600

800
0

50

time [sec]

(a)

400

throughput [Mbps]

0
0

time [sec]

200

12000
8000
4000

operations per second

10000
0

5000

operations per second

15000

10000
6000

operations per second

2000
0
0

100

150

50

time [sec]

(b)

100

150

time [sec]

(c)

(d)

50

100

150

200

250

time [sec]

(a)

20

40

60

80

throughput [Mbps]

0
0

100

20

40

60

80 100

time [sec]

time [sec]

(c)

(b)

200 400 600 800

15000
0

0
0

5000

operations per second

15000
5000

operations per second

15000
5000

operations per second

25000

Fig. 4. Time series of operations per second of sequential access workload: (a) local HDD only, (b) switch to local iSCSI, (c) switch to remote iSCSI, (d)
network throughput in the case of (c)

140

20

40

60

80 100

140

time [sec]

(d)

Fig. 5. Time series of operations per second of random access workload: (a) local HDD only, (b) switch to local iSCSI, (c) switch to remote iSCSI, (d)
network throughput in the case of (c)

After switching is finished, about 300 Mbps is used in the

sequential scenario and about 200 Mbps is used in the random
scenario. From these figures, we can verify that the prototype
implementation of the VSMM is working as we intended.

the VSMM, the benchmark performance improves more than

using only the local HDD.
In write operations, the performance of random write is
better than sequential access except in the case of the local
HDD, because sequential access incurs access to the swap
device every time it writes to memory, whereas random access
may hit the page on memory. And we can see that the
bandwidth used to write back is a dominant factor in the
performance in write operations because the write cache is
employed.

D. Basic Performance Measurement

To measure the basic performance of the VSMM, we
assumed that only one guest OS is going short of memory.
We conducted four types of micro-benchmark: sequential
write, random write, sequential read, and random read. These
micro-benchmarks first allocate 512 MB of memory area. The
sequential and random write benchmarks store 4 KB of data to
sequentially or randomly selected blocks 128,000 times, and
repeat it 20 times. The sequential and random read benchmarks
generate random data and store them to all the allocated
memory areas, then read data from sequentially or randomly
selected blocks 128,000 times and repeat it 20 times. Because
the guest OS has to use swap devices during storing 512 MB of
data, VSMM switches a virtual swap from a local HDD to an
iSCSI target in the early stage of the benchmark. We measured
the duration needed to finish these micro-benchmarks and
calculated an average 10 throughput of the process nearest
to the median (Table II). Rows 1 and 2 of Table II show the
throughput of the normal system using a swap device in the
HDD or SSD. Rows 3 7 give the throughput of the system
using the VSMM. This shows that in almost every case using

In read operations, the performance of sequential read is

better than that of random read, because the read ahead mechanism of the block device assigned to a virtual swap is in effect.
We can also see that the latency is a dominant factor in the
performance in read operations. Because a swap mechanism
used in the Linux kernel uses 4 KB pages, swapping out/in
memory to/from the swap device is done in 4 KB blocks.
Using a maximum transfer unit of the network interface (mtu)
larger than 4 KB achieves better performance than using an
mtu of less than 4,000 bytes because a 4 KB block can be
conveyed in a single packet. Moreover, VSMM outperforms
a swap device in a local SSD when PCs are connected using
10GbE with the mtu set at 9,000 bytes. This experiment shows
that using virtual swap through a local iSCSI yields the best
performance.

79

R EFERENCES

TABLE II
BASIC P ERFORMANCE OF VSMM
device
local HDD
local SSD
GbE mtu 1,500
GbE mtu 9,000
10GbE mtu 1,500
10GbE mtu 9,000
local iSCSI

write [MB/s]
seq.
random
21.58
15.24
25.67
40.10
19.48
25.34
18.91
23.43
27.41
38.17
26.43
35.97
33.96
42.49

[1] T. Newhall, S. Finney, K. Ganchev, and M. Spiegel, Nswap: A network

swapping module for Linux clusters, in Euro-Par03 International
Conference on Parallel and Distributed Computing, Aug. 2003.
[2] S. Pakin and G. Johnson, Performance analysis of a user-level memory
server, in IEEE International Conference on Cluster Computing, Sep.
2007.
[3] V. Roussev, I. Golden G. Richard, and D. Tingstrom, dRamDisk:
Efficient RAM sharing on a commodity cluster, in IEEE International
Performance Computing and Communications Conference, Apr. 2006.
[4] S. Liang, R. Noronha, and D. K. Panda, Swapping to remote memory
over InfiniBand: An approach using a high performance network block
device, in IEEE International Conference on Cluster Computing, Sep.
2005.
[5] Y. Chen, T. Wo, and J. Li, An efficient resource management system for
on-line virtual cluster provision, in 2009 IEEE International Conference
on Cloud Computing.
Los Alamitos, CA, USA: IEEE Computer
Society, 2009, pp. 7279.
[6] J. Z. Li, J. Chinneck, M. Woodside, and M. Litoiu, Deployment of
services in a cloud subject to memory and license constraints, in 2009
IEEE International Conference on Cloud Computing. Los Alamitos,
CA, USA: IEEE Computer Society, 2009, pp. 3340.
[7] C. Tang, M. Steinder, M. Spreitzer, and G. Pacifici, A scalable application placement controller for enterprise data centers, in WWW 07:
Proceedings of the 16th international conference on World Wide Web.
New York, NY, USA: ACM, 2007, pp. 331340.
[8] C. A. Waldspurger, Memory resource management in VMware ESX
server, in Fifth Symposium on Operating Systems Design and Implementation (OSDI02), Dec. 2002.
[9] D. Chianall, The Definitive Guide to the Xen Hypervisor. Prentice Hall,
Nov. 2007.
[10] P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neugebauer, I. Pratt, and A. Warfield, Xen and the art of virtualization, in
SOSP 03: Proceedings of the nineteenth ACM symposium on Operating
systems principles. New York, NY, USA: ACM, 2003, pp. 164177.
[11] D. von Suchodoletz and T. Zitterell, A new mission for the network
block device block scenario, Linux Magazine, pp. 6270, Sep. 2006.
[12] J. Satran, K. Meth, C. Sapuntzakis, M. Chadalapaka, and
E. Zeidner, Internet small computer systems interface (iSCSI),
RFC 3720 (Proposed Standard), Internet Engineering Task Force,
Apr. 2004, updated by RFCs 3980, 4850, 5048. [Online]. Available:
http://www.ietf.org/rfc/rfc3720.txt
[13] The iSCSI Enterprise Target Project, iSCSI enterprise target,
htp://iscsitarget.sourceforge.net/.
[14] A. Aizman and D. Yusupov, Open-iSCSI project: Open-iSCSI - rfc3720
architecture and implementation, http://www.open-iscsi.org/.

read [MB/s]
seq. random
13.11
4.71
29.94
12.75
18.69
14.49
25.73
20.63
29.72
30.34
35.74
32.10
41.81
34.26

VI. C ONCLUSION
We proposed a flexible memory exchange mechanism called
a VSMM, which can be used in cloud computing environments. Through the experiment, we conclude that the VSMM
can dynamically switch a virtual swap to/from remote memory
that achieves improvement in both performance and memory
usage. Moreover, this is performed transparently to a running
VM. Though current VSMM implementation is quite simple
in order to prove the feasibility and efficiency of the proposal,
a guest OS can use remote memory as a part of a virtual swap
to improve performance with no modification to the running
guest OS. It takes about 20 seconds to switch a virtual swap
from a local HDD to a remote iSCSI target. We are wondering
if this can be shortened by using off-load technology such
as the TCP and iSCSI off-load provided by certain network
interface cards.
We are currently conducting more realistic experiments
with real applications. Parts of the results show that the
configurable parameters mth and nhigh affect the applications
performance. Setting smaller nhigh can sensitively follow the
change of memory usage and use remote at the soonest
possible opportunity, but it may cause fluctuation of memory
exchange; importing and releasing repeatedly according to the
minor change of memory usage. The function for preventing
fluctuation phenomena is one planned enhancement for VSSM.
To optimize the performance and memory utilization of a
cloud environment, we will consider other decision criteria for
switching a virtual swap, such as network latency, available
bandwidth, and duration of potential usage of the remote
memory. CPU cycles of the exporting real machine involved
in exporting memory should also be considered. Our future
work includes development of a more sophisticated decision
algorithm for virtual swap switching, and an assignment
algorithm for remote memory, along with implementation of
the whole system.

80