Changes between Version 35 and Version 36 of FGBI


Ignore:
Timestamp:
10/06/11 23:01:16 (13 years ago)
Author:
lvpeng
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • FGBI

    v35 v36  
    5050
    5151Figures 2a, 2b, 2c, and 2d show the type I downtime com-
    52 parison among [wiki:FGBI FGBI], [wiki:LLM LLM], and [http://nss.cs.ubc.ca/remus/ Remus] mechanisms under Apache, NPB-EP,
     52parison among [wiki:FGBI FGBI], [wiki:LLM LLM], and [http://nss.cs.ubc.ca/remus/ Remus] mechanisms under Apache, [http://www.nas.nasa.gov/Resources/Software/npb.html NPB-EP],
    5353SPECweb, and SPECsys applications, respectively. The block size used in all
    5454experiments is 64 bytes. For [http://nss.cs.ubc.ca/remus/ Remus] and [wiki:FGBI FGBI], the checkpointing period is the
     
    7373rather than Figure 2a. In conclusion, compared with [wiki:LLM LLM], [wiki:FGBI FGBI] reduces the
    7474downtime by as much as 77%. Moreover, compared with [http://nss.cs.ubc.ca/remus/ Remus], [wiki:FGBI FGBI] yields a
    75 shorter downtime, by as much as 31% under Apache, 45% under NPB-EP, 39%
     75shorter downtime, by as much as 31% under Apache, 45% under [http://www.nas.nasa.gov/Resources/Software/npb.html NPB-EP], 39%
    7676under SPECweb, and 35% under SPECsys.
    7777
     
    8484main observations: (1) Their downtime results are very similar for "idle" run.
    8585This is because [http://nss.cs.ubc.ca/remus/ Remus] is a fast checkpointing mechanism and both [wiki:LLM LLM] and [wiki:FGBI FGBI] are based on it. There is rare memory update for "idle" run, so the type
    86 II downtime in all three mechanisms is short. (2) When running NPB-EP ap-
     86II downtime in all three mechanisms is short. (2) When running [http://www.nas.nasa.gov/Resources/Software/npb.html NPB-EP] ap-
    8787plication, the guest VM memory is updated at high frequency. When saved for
    8888the checkpoint, [wiki:LLM LLM] takes much more time to save huge "dirty" data caused
     
    9090much lower downtime than [http://nss.cs.ubc.ca/remus/ Remus] (reduce more than 70%) and [wiki:LLM LLM] (more
    9191than 90%). (3) When running Apache application, the memory update is not so
    92 much as that when running NPB, but the memory update is definitely more than
     92much as that when running [http://www.nas.nasa.gov/Resources/Software/npb.html NPB], but the memory update is definitely more than
    9393"idle" run. The downtime results shows [wiki:FGBI FGBI] still outperforms both [http://nss.cs.ubc.ca/remus/ Remus] and
    9494[wiki:LLM LLM].
     
    101101Figure 3a shows the overhead during VM migration. The figure compares the
    102102applications' runtime with and without migration, under Apache, SPECweb,
    103 NPB-EP, and SPECsys, with the size of the fine-grained blocks varies from 64
     103[http://www.nas.nasa.gov/Resources/Software/npb.html NPB-EP], and SPECsys, with the size of the fine-grained blocks varies from 64
    104104bytes to 128 bytes and 256 bytes. We observe that in all cases the overhead is
    105105low, no more than 13% (Apache with 64 bytes block). As we discuss in Section 3,
     
    112112In order to understand the respective contributions of the three proposed
    113113techniques (i.e., [wiki:FGBI FGBI], sharing, and compression), Figure 3b shows the break-
    114 down of the performance improvement among them under the NPB-EP bench-
     114down of the performance improvement among them under the [http://www.nas.nasa.gov/Resources/Software/npb.html NPB-EP] bench-
    115115mark. It compares the downtime between integrated [wiki:FGBI FGBI] (which we use for
    116116evaluation in this Section), [wiki:FGBI FGBI] with sharing but no compression support,
    117117[wiki:FGBI FGBI] with compression but no sharing support, and [wiki:FGBI FGBI] without sharing nor
    118 compression support, under the NPB-EP benchmark. As previously discussed,
    119 since NPB-EP is a memory-intensive workload, it should present a clear difference among the three techniques, all of which focus on reducing the memory-
     118compression support, under the [http://www.nas.nasa.gov/Resources/Software/npb.html NPB-EP] benchmark. As previously discussed,
     119since [http://www.nas.nasa.gov/Resources/Software/npb.html NPB-EP] is a memory-intensive workload, it should present a clear difference among the three techniques, all of which focus on reducing the memory-
    120120related overhead. We do not include the downtime of [wiki:LLM LLM] here, since for this
    121121compute-intensive benchmark, [wiki:LLM LLM] incurs a very long downtime, which is more