# Performance Analysis of Container Effect in Deep Learning Workloads and Implications
## 5 Flushing Dirty Pages to Secondary Storage  
In the previous section, we traced the statistics of dirty pages that were flushed to storage by kernel write-back calls while executing deep learning workloads. In this section, we further analyze the details of storage flush events. Specifically, we analyze the write-back activities as time progresses and the ratio of write-back triggering reasons (e.g., periodic, background, and sync). The most common cause of write-backs is \"periodic,\" which is \begin{table}
\begin{tabular}{p{42.7 pt} p{56.9 pt} p{56.9 pt} p{56.9 pt} p{56.9 pt} p{56.9 pt}} \hline \hline
**Rank** & **Task** & **File** & **Location** & **Cause** & **Percent** \\ \hline
1 & docker & /usr/lib/x86\_64-linux- gnu/ld-linux-x86-64.so.2 & \_dl\_relocate\_object & Shared library injection & 6.2 \\ \hline
2 & docker-buildx & /usr/libexec/docker/cliplugins/docker-buildx & runtime.memclrNoHeapPointers & Garbage Collection & 5.1 \\ \hline
3 & docker & /usr/bin/docker & runtime.(*spanSet).push & Container start new command & 4.5 \\ \hline
4 & docker-buildx & /usr/libexec/docker/cliplugins/docker-buildx & runtime.(*spanSet).push & Container start new command & 3.8 \\ \hline
5 & docker & /usr/bin/docker & runtime.memclrNoHeapPointers & Garbage Collection & 3.0 \\ \hline
6 & docker-buildx & /usr/libexec/docker/cliplugins/docker-buildx & runtime.memmove & Memory Copy & 2.8 \\ \hline
7 & docker & /usr/bin/docker & runtime.memmove & Memory Copy & 2.5 \\ \hline
8 & docker & /usr/bin/docker & runtime.getempty & Container first start command & 1.9 \\ \hline
9 & ML process & /usr/libexec/docker/cliplugins/docker-buildx & runtime.(*spanSet).push & Container start new command & 1.6 \\ \hline
10 & docker- compose & /usr/libexec/docker/cliplugins/docker-compose & 0 xb239 & Heap & 1.5 \\ \hline \hline \end{tabular}
\end{table} 
Table 8: System call frequency distributions. activated periodically on a schedule. These periodic write-backs ensure that dirty pages are flushed to storage within a certain time window regardless of the situation of the system. Another common cause of write-backs is \"background,\" which is triggered when the ratio of dirty pages in memory exceeds a certain threshold. Note that periodic and background write-backs are not explicitly requested by a user space process but are performed by the kernel. In contrast, \"sync\" can be requested explicitly by a user process to flush all dirty data to storage, regardless of the reason for the write-back operation. Frequent invocation of \"sync\" may slow down the entire system so it should only be used if we need to flush all dirty data to storage. Tables 9 and 10 show the frequency and ratio of write-backs based on call reasons in single and multiple Docker environments, respectively. As shown in Table 9, \"periodic\" accounts for the majority of write-backs (68.1-81.5%) in single Docker environments, but there is also a certain portion of \"background\" write-backs of 18.4-31.6%. Note that \"background\" write-backs are difficult to estimate, so they may degrade the performance of the entire system. Note also that the ratio of \"background\" write-backs grows even more in multi-tenant environments (by up to 42.1%) as shown in Table 10. This is because multi-tenants use more memory space, so \"background\" write-backs are triggered more frequently to reduce dirty pages in memory. Based on this result, we can conclude that multi-tenants incur more unpredictable write-backs, causing efficient management of flush I/Os difficult. Also, the differences observed between the two environments suggest that each requires a customized approach to manage the write-back process. Reducing the number of write-backs can be achieved by appropriately setting the write-back parameters or using a file system that supports asynchronous writing. However, setting appropriate parameters in deep learning varies depending on the model and the number of tenants (i.e., single or multi-tenant).