Changes between Version 16 and Version 17 of FGBI

Timestamp:

09/28/11 00:00:58 (13 years ago)

Author:

lvpeng

Comment:

--

FGBI

@@ -84 +84 @@
 LLM.
 
+== Overhead ==
+Figure 5a shows the overhead during VM migration. The figure compares the
+applications' runtime with and without migration, under Apache, SPECweb,
+NPB-EP, and SPECsys, with the size of the fine-grained blocks varies from 64
+bytes to 128 bytes and 256 bytes. We observe that in all cases the overhead is
+low, no more than 13% (Apache with 64 bytes block). As we discuss in Section 3,
+the smaller the block size that FGBI chooses, the greater is the memory overhead
+that it introduces. In our experiments, the smaller block size that we chose is 64
+bytes, so this is the worst case overhead compared with the other block sizes.
+Even in this "worst" case, under all these benchmarks, the overhead is less than
+8.21%, on average.
+
+In order to understand the respective contributions of the three proposed
+techniques (i.e., FGBI, sharing, and compression), Figure 5b shows the break-
+down of the performance improvement among them under the NPB-EP bench-
+mark. It compares the downtime between integrated FGBI (which we use for
+evaluation in this Section), FGBI with sharing but no compression support,
+FGBI with compression but no sharing support, and FGBI without sharing nor
+compression support, under the NPB-EP benchmark. As previously discussed,
+since NPB-EP is a memory-intensive workload, it should present a clear differ-
+ence among the three techniques, all of which focus on reducing the memory-
+related overhead. We do not include the downtime of LLM here, since for this
+compute-intensive benchmark, LLM incurs a very long downtime, which is more
+than 10 times the downtime that FGBI incurs.
+
+We observe from Figure 5b that if we just apply the FGBI mechanism without
+integrating sharing or compression support, the downtime is reduced, compared
+with that of Remus in Figure 4b, but it is not significant (reduction is no more
+than twenty percent). However, compared with FGBI with no support, after in-
+tegrating hybrid compression, FGBI further reduces the downtime, by as much
+as 22%. We also obtain a similar benefit after adding the sharing support (down-
+time reduction is a further 26%). If we integrate both sharing and compression
+support, the downtime is reduced by as much as 33%, compared to FGBI without
+sharing or compression support.