Cleaned up, finished? w15 slides
This commit is contained in:
parent
b8904cd213
commit
904216dc58
23 changed files with 110 additions and 1751 deletions
Binary file not shown.
|
|
@ -1,6 +1,7 @@
|
|||
\documentclass{beamer}
|
||||
\usepackage[]{biblatex}
|
||||
\usepackage[export]{adjustbox}
|
||||
\usepackage{hyperref}
|
||||
|
||||
\title{
|
||||
Cache Coherency \& Memory Model in RDMA-Backed Software-Coherent DSM
|
||||
|
|
@ -209,6 +210,49 @@
|
|||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Protocol Overview}
|
||||
\begin{itemize}
|
||||
\item {
|
||||
Multiple readers can exist for a clean page -- the page is
|
||||
\textbf{shared}.
|
||||
}
|
||||
\item {
|
||||
Only one writer is allowed for a clean page -- the page becomes
|
||||
\textbf{exclusive}.
|
||||
}
|
||||
\item {
|
||||
For one writer node be allowed sole write access to some page, all
|
||||
other sharers need to have their page cache invalidated prior to
|
||||
making the change global (commit-invalidate).
|
||||
}
|
||||
\item {
|
||||
While the sole writer node has not yet committed, either:
|
||||
\begin{itemize}
|
||||
\item {
|
||||
no other reader or writer nodes are allowed to be served
|
||||
this page (stronger consistency model).
|
||||
}
|
||||
\item {
|
||||
no writers are allowed to be served this page. Readers can
|
||||
be served stale data (provided data providers do not receive
|
||||
invalidation message prior to service).
|
||||
}
|
||||
\end{itemize}
|
||||
}
|
||||
\item {
|
||||
When the sole writer commits, it becomes the sole home node
|
||||
(data provider) which serves the updated page content.
|
||||
\begin{itemize}
|
||||
\item {
|
||||
Optionally, some nodes can register to have commits written
|
||||
back instead.
|
||||
}
|
||||
\end{itemize}
|
||||
}
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Protocol Excerpt: Write-Invalidate}
|
||||
\begin{figure}
|
||||
|
|
@ -224,20 +268,21 @@
|
|||
\frametitle{Consistency Model: TSO}
|
||||
\begin{itemize}
|
||||
\item {
|
||||
Total Store Ordering allows Reads to bypass Stores.
|
||||
Total Store Ordering allows Reads to overtake Stores.
|
||||
}
|
||||
\item {
|
||||
Assuming correct use of node-local synchronization on all nodes,
|
||||
applying TSO in a home-based DSM allows for:
|
||||
\begin{itemize}
|
||||
\item {
|
||||
When another node tries to read T-page from access-control
|
||||
node: W$\rightarrow$R violation.
|
||||
Another node tries to read T-page from access-control
|
||||
node, served stale data: W$\rightarrow$R violation.
|
||||
}
|
||||
\item {
|
||||
When another node tries to read S-page from data-provider
|
||||
nodes: W$\rightarrow$R violation (if e.g., the invalidation
|
||||
message from access-control node was received afterwards).
|
||||
Another node tries to read S-page from data-provider
|
||||
nodes, served stale data: W$\rightarrow$R violation
|
||||
(if e.g., the invalidation message from access-control node
|
||||
was received afterwards).
|
||||
}
|
||||
\item {
|
||||
Data-provider and access-control nodes work on one request
|
||||
|
|
@ -285,8 +330,8 @@
|
|||
\end{itemize}
|
||||
}
|
||||
\item {
|
||||
Auto-share: likewise, write-back pages to non-data-provider nodes to
|
||||
take advantage of 1-sided communications.
|
||||
Auto-share: likewise, write-back pages to non-data-provider nodes,
|
||||
which takes advantage of 1-sided communications provided by RDMA.
|
||||
}
|
||||
\item {
|
||||
Request aggregation: aggregate RDMA transfers for optimal transfer
|
||||
|
|
@ -339,7 +384,7 @@
|
|||
shared page.
|
||||
}
|
||||
\item {
|
||||
Message variants are not finalized:
|
||||
Problem: Message variants are not finalized:
|
||||
\begin{itemize}
|
||||
\item {
|
||||
Goal: Composable message chains that allow for
|
||||
|
|
@ -404,6 +449,9 @@
|
|||
is it absolutely necessary to export new symbols for such an
|
||||
important operation?
|
||||
}
|
||||
\item {
|
||||
Repository: \url{https://github.com/rubberhead/unnamed_ba_thesis.git}.
|
||||
}
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
|
|
@ -440,9 +488,9 @@
|
|||
writeback/invalidate cache entries.
|
||||
}
|
||||
\item {
|
||||
Problem: Can only be called in process context (for userspace
|
||||
virtual addresses) or in all contexts
|
||||
(for kernel virtual addresses)?
|
||||
Problem: Can only be called in process context (for user
|
||||
virtual addresses) or in all contexts (for kernel virtual
|
||||
addresses)?
|
||||
}
|
||||
\end{itemize}
|
||||
}
|
||||
|
|
@ -463,7 +511,8 @@
|
|||
\item {
|
||||
Longish-term solution: arrange kernel module code in a way
|
||||
that takes advantage of existing driver API
|
||||
(e.g., via DMA API, for example \textit{smbdirect}).
|
||||
(e.g., via DMA API, which for example \textit{smbdirect}
|
||||
uses).
|
||||
}
|
||||
\end{itemize}
|
||||
}
|
||||
|
|
@ -473,6 +522,13 @@
|
|||
}
|
||||
\item {
|
||||
Exports symbol into separate header file.
|
||||
\begin{itemize}
|
||||
\item {
|
||||
Declared in
|
||||
\texttt{arch/arm64/include/asm/cacheflush\_extra.h}.
|
||||
}
|
||||
\item Defined in \texttt{arch/arm64/mm/flush.c}.
|
||||
\end{itemize}
|
||||
}
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
|
@ -528,23 +584,49 @@
|
|||
|
||||
\begin{frame}
|
||||
\frametitle{4. Future Work}
|
||||
\begin{enumerate}
|
||||
\begin{itemize}
|
||||
\item {
|
||||
Incorporate cache coherence mechanism into the larger project.
|
||||
}
|
||||
\item {
|
||||
Implement memory model within the larger project. This involves:
|
||||
\begin{itemize}
|
||||
TBD:
|
||||
\begin{enumerate}
|
||||
\item {
|
||||
Making adjustment to message type and structure specifications
|
||||
for better inter-operation with RDMA.
|
||||
Incorporate cache coherence mechanism into the larger
|
||||
project.
|
||||
}
|
||||
\item {
|
||||
Implement memory model programmatically.
|
||||
Implement memory model within the larger project. This
|
||||
involves:
|
||||
\begin{itemize}
|
||||
\item {
|
||||
Making adjustment to message type and structure
|
||||
specifications for better inter-operation with RDMA.
|
||||
}
|
||||
\item {
|
||||
Implement memory model programmatically.
|
||||
}
|
||||
\end{itemize}
|
||||
}
|
||||
\end{itemize}
|
||||
\end{enumerate}
|
||||
}
|
||||
\end{enumerate}
|
||||
\item {
|
||||
Further Studies:
|
||||
\begin{enumerate}
|
||||
\item {
|
||||
Swappable RDMA memory region.
|
||||
\begin{itemize}
|
||||
\item {
|
||||
As of now, all DMA pages are non-swappable -- they
|
||||
must be allocated using the SLAB/SLUB allocator for
|
||||
kernel memory, or via GFP page allocators.
|
||||
}
|
||||
\end{itemize}
|
||||
}
|
||||
\item {
|
||||
Automatic frequent sharer detection for MUX-ing between
|
||||
commit-invalidation and commit-writeback.
|
||||
}
|
||||
\end{enumerate}
|
||||
}
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
% References
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue