% Yeah "slices" whatever lol
\documentclass{beamer}
\usepackage[style=authortitle-comp]{biblatex}
\usepackage[export]{adjustbox}

\title{Progress Report: Page Cache Consistency Model}
\author{Zhengyi Chen}
\date{\today}

\addbibresource{../main.bib}

\begin{document}
% Title page
\frame{\titlepage}

% Page -2
\begin{frame}
    \frametitle{
        Literature Review: (Shan, Tsai, \& Zhang. 2017\footcite{shan2017distributed})
    }
    \begin{itemize}
        \item {
            Concerns with the sharing of persistent memory --
            \begin{itemize}
                \item More or less similar to sharing regular memory, but\dots
                \item Data replication is key $\Rightarrow$ Multiple data provider.
            \end{itemize}
        }
        \item {
            Supports both Multi-Writer Multi-Reader and Multi-Writer Single-Writer Protocols
            \begin{itemize}
                \item MRMW ``support(s) great parallelism''
                \item MRSW enables ``stronger consistency''
            \end{itemize}
        }
        \item {
            Makes distinction between 3 variants of nodes:
            \begin{itemize}
                \item Commit Node -- Node who wishes to commit changes wrt. the system.
                \item Owner Node -- Node(s) who act as data provider for latest page content.
                \item Manager Node -- Node who provide (serialized) write access control to page.
            \end{itemize}
        }
    \end{itemize}
\end{frame}

\begin{frame}
    \frametitle{
        Literature Review: (Shan, Tsai, \& Zhang. 2017\footcite{shan2017distributed})
    }
    \begin{itemize}
        \item {
            For data replication and fault tolerance, necessitates:
            \begin{enumerate}
                \item Commit status logging (akin to journaled file system)
                \item Persistent Commit ID
                \item \textbf{Required} deg. of replication -- each ON shares to $N$ nodes.
            \end{enumerate}
        }
        \item {
            Fault tolerance is out of this thesis's scope. However\dots
            \begin{itemize}
                \item Prob. no need for requiring any degree of data replication.
                \item Dropping data replication req. $\Rightarrow$ no need for replication comms.
                \item Commit status logging \& persistent CID can be helpful \& should not introduce additional comms.
            \end{itemize}
        }
        \item {
            MRSW provides ``simpler and more efficient'' commits than MRMW -- no concurrent
            commits to same shared memory object exists.
            \begin{itemize}
                \item Also makes more sense from a CPU-accelerator dichotomy outlook (ofc. wrt. this thesis's system).
            \end{itemize}
        }
    \end{itemize}
\end{frame}

\begin{frame}
    \frametitle{MRSW: (Shan, Tsai, \& Zhang. 2017\footcite{shan2017distributed})}
    \begin{figure}
        \includegraphics[width=\linewidth]{w12_slides_resources/dspm.fig8.png}
    \end{figure}
    Note: CN: Node 1, MN: Node 2, ON: Node 2 \& 3. Node 4 may or may not already
    share the committed page prior to acquire.
\end{frame}

% Page 0
\begin{frame}
    \frametitle{Literature Review: (Ramesh. 2023)}
    \begin{itemize}
        \item Popcorn-derived.
        \item {
            Sequential consistency, MRSW protocol offloaded onto sNIC:
            \begin{itemize}
                \item DSM protocol processor implemented on sNIC FPGA core.
                \item sNIC \textbf{keeps track of memory ownership, status, R/W permissions} at page level granularity.
                \item Removes the need for distinct memory management nodes.
                \item (i.e., the sNIC IS the memory management node -- except of course allocation).
            \end{itemize}
        }
        \item {
            Similar idea occurred in \textit{Concordia}\footcite{wang2021concordia}:
            \begin{itemize}
                \item Concurrency control and multicast offloaded to network switch.
                \item Authors claim this is more scalable (?)
            \end{itemize}
        }
    \end{itemize}
    \footnote{
        Ramesh., ``SNIC-DSM: SmartNIC based DSM Infrastructure for Heterogeneous-ISA Machines''
    }
\end{frame}

\begin{frame}
    \frametitle{Literature Review: (Endo, Sato, \& Taura. 2020)\footcite{EndoWataru2020MADD}}
    \begin{itemize}
        \item MRMW: use timestamps to store reader ``intervals''.
        \item {
            Introduces the home-migration concept:
            \begin{itemize}
                \item At commit, make the CN the home node instead of invalidating the home node.
                \item This removes communications needed for diff-merging at home node -- this can be done locally.
                \item No support for multiple home nodes.
            \end{itemize}
        }
        \item {
            No performance improvement over PGAS programming framework (OpenMPI).
        }
    \end{itemize}
\end{frame}

\begin{frame}
    \frametitle{Literature Review: (Endo, Sato, \& Taura. 2020)\footcite{EndoWataru2020MADD}}
    \begin{figure}
        \includegraphics[width=\linewidth]{w12_slides_resources/menps.fig5.png}
    \end{figure}
\end{frame}

% Page 1
\begin{frame}
    \frametitle{The System}
    \begin{itemize}
        \item Remote node(s) abstracted as shared memory device ``\texttt{/dev/rshm}''
        \item {
            Heterogeneous Memory Management (HMM) ensures unified address space between
            local and device memory.
        }
        \item {
            Migration of pages between CPU and ``device'' is transparent to userspace
            -- no need for copying/mapping.
        }
        \item {
            In reality, ``\texttt{/dev/rshm}'' a handler for RDMA access between nodes.
            \begin{itemize}
                \item This involves remote read/write and moving page content between nodes.
                \item Local node serves as \emph{home node \& address space host} at share time.
                \item Remote nodes attached on \texttt{/dev/rshm} as accelerator.
            \end{itemize}
        }
    \end{itemize}
\end{frame}

% Page 2
\begin{frame}
    \frametitle{The Problem: Consistency Protocol}
    \begin{itemize}
        \item Single-Writer, Multiple-Reader Protocol
        % Why?
        % It may be that this mimics all sorts of logic for hardware acceleration
        % -- that is, in an HMM node each PCIe device have sole access to a page of memory.
        % For example, during machine learning you naturally can't access the same, say,
        % kernel by both CPU and GPU.
        % That said, I never shed a doubt on this issue except my advisor telling me not
        % to worry about it -- if I was asked this problem for some reason I'd be cooked!
        \item Need to be performant\dots with some ergonomics
        \item {
            Two Hypothetical Protocols:
            \begin{itemize}
                \item ``RwLock'' Consistency Protocol
                \item Acq-Rel Consistency Protocol
            \end{itemize}
        }
        \item {
            Former ensures \emph{strong} single-writer consistency
            \begin{itemize}
                \item -- Also easier to program with!
            \end{itemize}
        }
        \item Latter allows concurrent in-memory \emph{non-committal} computation
    \end{itemize}
\end{frame}

% Page 3
\begin{frame}
    \frametitle{``RwLock'' Consistency Protocol}
    Similar to a read-write lock where:
    \begin{itemize}
        \item Multiple readers can exist for a clean page -- the page is \textbf{shared}.
        \item Only one write is allowed for a clean page -- the page becomes \textbf{exclusive}.
        \item {
            For one writer node to be allowed sole write access to some page, all other
            readers need to have their page cache invalidated.
        }
        \item {
            While the sole writer node has not yet committed, no other reader or writer nodes
            are allowed to be served this page.
        }
        \item {
            When the sole writer commits, it becomes the new home node which serves the
            updated page content.
        }
    \end{itemize}
\end{frame}

% Page 4
\begin{frame}
    \frametitle{``RwLock'' Consistency Protocol}
    \begin{figure}
        \centering
        \includegraphics[width=\linewidth]{
            w12_slides_resources/Fig-RwLockProtocol 2023-12-04 21_03_50.pdf
        }
    \end{figure}
    Note: The blue arrow should be acknowledged via commit by P3 to P1 --
    forgot to put the ack. arrow in.
\end{frame}

% Page 5
\begin{frame}
    \frametitle{Acq-Rel Consistency Protocol}
    In RwLock's case, read requests result in installation of read-only pages at
    remote nodes.

    Alternatively, this protocol allows read/write pages to be installed at remote
    nodes at read time. Such writes are \emph{non-committal} and cannot be synced
    with the entire system.

    To summarize:
    \begin{itemize}
        \item {
            ``Readers'' can write to its locally installed page without any means
            to synchronize the change.
        }
        \item {
            ``Writers'' need to acquire global write access from the \emph{PT node},
            which invalidates all shared pages.
        }
        \item {
            i.e., Instead of write-invalidate, perform acquire-invalidate.
        }
    \end{itemize}

    This may require pages to be marked as CoW if the sharer wants also to act as a home node.
\end{frame}

% Page 6
\begin{frame}
    \frametitle{Consistency Protocol: Knobs and Mods}
    We can modify these two protocols further as follows:
    \begin{itemize}
        \item {
            Multi-home Protocol: instead of having one home at a time, have
            multiple homes (e.g., when writer commits) to prevent network bottleneck.
            \begin{itemize}
                \item Extra metadata can limit scalability (e.g., granularity of directories)
            \end{itemize}
        }
        \item {
            Auto-share: Automatically share pages at commit time using 1-way
            communications.
            \begin{itemize}
                \item Potential for communication reduction -- debatable.
            \end{itemize}
        }
    \end{itemize}
\end{frame}

\begin{frame}
    \frametitle{Why this design?}
    \begin{itemize}
        \item Largely inspired by DSPM\footcite{shan2017distributed}.
        \item Removed arrows for enforced data duplication -- duplication is solely on-demand.
        \item {
            Introduces transitional state ``T'':
            \begin{itemize}
                \item Used to flag a page as unserviceable -- visible only at MN.
                \item All read/write access to T-page is kept on hold until MN receives commit msg.
                \item After commit, MN forwards queued R/W access to moved home.
                \item This (at least) maintains RAW, WAW data dependency for whichever issue serialization.
                \item Removing T allows stale data to be served -- violates RAW for better throughput.
            \end{itemize}
        }
        \item Extensible (as mentioned in prior page).
    \end{itemize}
\end{frame}

\begin{frame}
    \frametitle{Why not this design?}
    At the very least\dots
    \begin{itemize}
        \item {
            De-coupled home and access-management nodes require:
            \begin{itemize}
                \item Each home node need to be MN-aware (easy).
                \item {
                    MN need to be home-aware (also easy with single-writer, but spatial complexity is a concern):
                    \begin{itemize}
                        \item Naive directory scheme is not scalable.
                        \item Coarse directory scheme (e.g., SGI Origin 2000) is wasteful (but may be the fastest in practice).
                        \item Distributed directory scheme may provide terrible latency.
                        \item More sophisticated schemes are possible but needs work \& experimentation.
                    \end{itemize}
                }
            \end{itemize}
        }
        \item Strict consistency limits throughput.
    \end{itemize}
\end{frame}

% Page 7
\begin{frame}
    \frametitle{What about Consistency \textbf{Model}?}
    \begin{itemize}
        \item {
            The weaker a consistency model is, the more difficult it is to program with.
            \begin{itemize}
                \item {
                    Weak ordering architectures (e.g., ARMv8) more or less depends on
                    compiler/interpreter to emit barriers as see fit \footcite{Haynes_2022}.
                }
                \item {
                    Bad for usability/portability -- programs may need
                    to be compiled using a modified toolchain, else need to add these
                    synchronization instructions/function calls everywhere.
                }
            \end{itemize}
        }
        \item {
            \footcite{cai2018efficient} uses Partial Store Order.
            \begin{itemize}
                \item Preserves RAR, WAR -- ``synchronous read\dots asynchronous write''
                \item Easier to use than relaxed ordering.
            \end{itemize}
        }
        \item {
            \footcite{wang2021concordia} uses strong consistency, but warns about its scalability.
        }
    \end{itemize}
\end{frame}

% Page 8
\begin{frame}
    \frametitle{Consistency Model: Cont.}
    \begin{itemize}
        \item {
            Similar to Concordia\footcite{wang2021concordia}, the proposed protocols also assume
            strong consistency.
        }
        \item {
            Further work needed to see how to adapt these protocols for weaker consistency models.
        }
    \end{itemize}
\end{frame}
\end{document}