Academia.eduAcademia.edu

Figure 4 – uploaded by Zhiling Lan

See full PDFdownloadDownload figure
The post-checkpoint tracking overhead is mainly caused by three factors: the PTE scan time, the descriptor search and insertion time, and the I/O time to store the descriptor. Table 3 lists the measured post-checkpoint tracking overheads. We have observed

Table 3 The post-checkpoint tracking overhead is mainly caused by three factors: the PTE scan time, the descriptor search and insertion time, and the I/O time to store the descriptor. Table 3 lists the measured post-checkpoint tracking overheads. We have observed

Related Figures (8)

reduction of restart latency. Further, the principle of FREM is applicable to general C/R protocols. The post-checkpoint tracking phase is composed of [wo steps:
reduction of restart latency. Further, the principle of FREM is applicable to general C/R protocols. The post-checkpoint tracking phase is composed of [wo steps:
Figure 2. Pitfalls in the identification of the touch set caused by dynamic memory management 4.1.3. Dynamic memory management. Dynamic memory allocation and deallocation operations change the process address space. Without a careful analysis, they may cause identification errors. As shown in Figure 2, we identify three types of pitfalls stemming from dynamic memory usage.
Figure 2. Pitfalls in the identification of the touch set caused by dynamic memory management 4.1.3. Dynamic memory management. Dynamic memory allocation and deallocation operations change the process address space. Without a careful analysis, they may cause identification errors. As shown in Figure 2, we identify three types of pitfalls stemming from dynamic memory usage.
Table 2. Restart latency (RL) by using BLCR and FREM with SPEC CPU2006 applications. The parenthesized numbers in the last two columns are relative improvements (in percentage) achieved by FREM.
Table 2. Restart latency (RL) by using BLCR and FREM with SPEC CPU2006 applications. The parenthesized numbers in the last two columns are relative improvements (in percentage) achieved by FREM.
The benchmark suite SPEC CPU2006 is tested in our experiments [21]. Since FREM targets the applications with large memory consumptions, we choose the applications whose memory footprints are greater than 150 MB. Among these applications, we randomly select twelve applications and present their results in the following.
The benchmark suite SPEC CPU2006 is tested in our experiments [21]. Since FREM targets the applications with large memory consumptions, we choose the applications whose memory footprints are greater than 150 MB. Among these applications, we randomly select twelve applications and present their results in the following.
Figures 4 and 5 show, respectively, the raw improvement and the relative improvement on restart latency achieved by FREM over BLCR. As we can see from Figure 4, the reduction ranges from a couple of seconds to a couple of hundred seconds. The highest reduction is 152.6 seconds in the FAST network and 208.5 seconds in the SLOW network. According to Figure 5, except for applications 8 and 9, the relative improvement is more than 53.78% in the SLOW network and more than 49.25% in the FAST network. The trivial improvements on applications 8 and 9 are attributed to their low temporal data locality. For instance, for application 8, its touch set is 402 MB, which is very close to the checkpoint image of 409 MB; for application 9, the improvement achieved by FREM drops sharply when the network performance is changed from FAST to SLOW. This is also caused by the rapid growth of the touch set when the network performance is low. However, we shall point out that even in a slow network, the raw restart latency is still reduced by at least a couple of seconds.
Figures 4 and 5 show, respectively, the raw improvement and the relative improvement on restart latency achieved by FREM over BLCR. As we can see from Figure 4, the reduction ranges from a couple of seconds to a couple of hundred seconds. The highest reduction is 152.6 seconds in the FAST network and 208.5 seconds in the SLOW network. According to Figure 5, except for applications 8 and 9, the relative improvement is more than 53.78% in the SLOW network and more than 49.25% in the FAST network. The trivial improvements on applications 8 and 9 are attributed to their low temporal data locality. For instance, for application 8, its touch set is 402 MB, which is very close to the checkpoint image of 409 MB; for application 9, the improvement achieved by FREM drops sharply when the network performance is changed from FAST to SLOW. This is also caused by the rapid growth of the touch set when the network performance is low. However, we shall point out that even in a slow network, the raw restart latency is still reduced by at least a couple of seconds.
Table 3. Post-checkpoint tracking overhead (in milliseconds) Table 4. Fast restart overhead (time unit: seconds)
Table 3. Post-checkpoint tracking overhead (in milliseconds) Table 4. Fast restart overhead (time unit: seconds)
Related topics:
High Performance ComputingInformation RetrievalComputer NetworksImage Retrieval
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved