Changes between Version 11 and Version 12 of FGBI

Timestamp:

09/27/11 23:53:59 (13 years ago)

Author:

lvpeng

Comment:

--

FGBI

@@ -40 +40 @@
 illustrating the memory saving potential, we present two supporting
 techniques: block sharing and hybrid compression.
+
+== Downtime Evaluations ==
+Type I Downtime. Figures 4a, 4b, 4c, and 4d show the type I downtime com-
+parison among FGBI, LLM, and Remus mechanisms under Apache, NPB-EP,
+SPECweb, and SPECsys applications, respectively. The block size used in all
+experiments is 64 bytes. For Remus and FGBI, the checkpointing period is the
+time interval of system update migration, whereas for LLM, the checkpointing
+period represents the interval of network buffer migration. By configuring the
+same value for the checkpointing frequency of Remus/FGBI and the network
+buffer frequency of LLM, we ensure the fairness of the comparison. We observe
+that Figures 4a and 4b show a reverse relationship between FGBI and LLM.
+Under Apache (Figure 4a), the network load is high but system updates are
+rare. Therefore, LLM performs better than FGBI, since it uses a much higher
+frequency to migrate the network service requests. On the other hand, when
+running memory-intensive applications (Figure 4b and 4d), which involve high
+computational loads, LLM endures a much longer downtime than FGBI (even
+worse than Remus).
+Although SPECweb is a web workload, it still has a high page modifi-
+cation rate, which is approximately 12,000 pages/second [4]. In our experi-
+ment, the 1 Gbps migration link is capable of transferring approximately 25,000
+pages/second. Thus, SPECweb is not a lightweight computational workload for
+these migration mechanisms. As a result, the relationship between FGBI and
+LLM in Figure 4c is more similar to that in Figure 4b (and also Figure 4d),
+rather than Figure 4a. In conclusion, compared with LLM, FGBI reduces the
+downtime by as much as 77%. Moreover, compared with Remus, FGBI yields a
+shorter downtime, by as much as 31% under Apache, 45% under NPB-EP, 39%
+under SPECweb, and 35% under SPECsys.
+Type II Downtime. Table 1 shows the type II downtime comparison among
+Remus, LLM, and FGBI mechanisms under different applications. We have three
+main observations: (1) Their downtime results are very similar for "idle" run.
+This is because Remus is a fast checkpointing mechanism and both LLM and
+FGBI are based on it. There is rare memory update for \idle" run, so the type
+II downtime in all three mechanisms is short. (2) When running NPB-EP ap-
+plication, the guest VM memory is updated at high frequency. When saved for
+the checkpoint, LLM takes much more time to save huge \dirty" data caused
+by its low memory transfer frequency. Therefore in this case FGBI achieves a
+much lower downtime than Remus (reduce more than 70%) and LLM (more
+than 90%). (3) When running Apache application, the memory update is not so
+much as that when running NPB, but the memory update is definitely more than
+"idle" run. The downtime results shows FGBI still outperforms both Remus and
+LLM.
+