[RFC PATCH 0/7] Import 'TRANSITIVITY' section

[RFC PATCH 0/7] Import 'TRANSITIVITY' section

[Akira Yokosawa]

From 461f7d8b71f955c17ce30585b301834c3ad4026b Mon Sep 17 00:00:00 2001
From: Akira Yokosawa <akiyks@gmail.com>
Date: Sat, 25 Mar 2017 17:54:01 +0900
Subject: [RFC PATCH 0/7] Import 'TRANSITIVITY' section

Hi Paul,

As has been being discussed off the list, I'm attempting to update
"Memory Barriers" section to catch up memory-barriers.txt.

This patch set imports "TRANSITIVITY" section and do some tweaks
for better LaTeX typesetting.

Patch 1 imports the section mostly as is.
Patch 5 diverts from current memory-barriers.txt in the way to
present code snippets.
Patches 2 and 7 are updates for issues in previous sections I noticed
while doing this work.

Although we need further updates, especially to replace "LOCK/UNLOCK"
with "ACQUIRE/RELEASE" to go along with changes in memory-barriers.txt,
this patch set seems worthy on its own.

Thoughts?
                                  Thanks, Akira
--

Akira Yokosawa (7):
  advsync: Import 'TRANSITIVITY' section from memory-barriers.txt
  advsync: Permit p (page) placement for consecutive wide figures
  advsync: Make code snippet in deference to Herman Hollerith float
  advsync: Add footnote on transitivity
  advsync: Make code snippets more asm like
  advsync: Properly use nbsp in initial values
  advsync: Avoid indent after minipage

 advsync/memorybarriers.tex | 207 ++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 195 insertions(+), 12 deletions(-)

-- 
2.7.4

[RFC PATCH 1/7] advsync: Import 'TRANSITIVITY' section from memory-barriers.txt

[Akira Yokosawa]

From 9df6a5d3eb65c67b79f8d15ee7928d617eae2c47 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa <akiyks@gmail.com>
Date: Sat, 25 Mar 2017 17:42:06 +0900
Subject: [RFC PATCH 1/7] advsync: Import 'TRANSITIVITY' section from memory-barriers.txt

Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
 advsync/memorybarriers.tex | 175 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 175 insertions(+)

diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
index 15ed1f6..efc2cbd 100644
--- a/advsync/memorybarriers.tex
+++ b/advsync/memorybarriers.tex
@@ -2536,6 +2536,181 @@ as shown in Figure~\ref{fig:advsync:Speculative Loads Cancelled by Barrier}.
 \ContributedBy{Figure}{fig:advsync:Speculative Loads Cancelled by Barrier}{David Howells}
 \end{figure*}

+\subsubsection{Transitivity}
+\label{sec:advsync:Transitivity}
+
+``Transitivity'' is a deeply intuitive notion about ordering that is not
+always provided by real computer systems.  The following example
+demonstrates transitivity with initial values of
+{\tt \{X = 0, Y = 0\}}:
+
+\vspace{5pt}
+\begin{minipage}[t]{\columnwidth}
+\tt
+\scriptsize
+\begin{tabular}{l|l|l}
+	\nf{CPU 1}	& \nf{CPU 2}		& \nf{CPU 3} \\
+	\hline
+	X = 1;		& LOAD X		& Y = 1; \\
+			& <general barrier>	& <general barrier> \\
+			& LOAD Y		& LOAD X \\
+\end{tabular}
+\end{minipage}
+\vspace{5pt}
+
+Suppose that CPU~2's load from~\co{X} returns~1 and its load from~\co{Y} returns~0.
+This indicates that CPU~2's load from~\co{X} in some sense follows CPU~1's
+store to~\co{X} and that CPU~2's load from~\co{Y} in some sense preceded CPU~3's
+store to~\co{Y}.  The question is then ``Can CPU~3's load from~\co{X} return~0?''
+
+Because CPU~2's load from~\co{X} in some sense came after CPU~1's store, it
+is natural to expect that CPU~3's load from~\co{X} must therefore return~1.
+This expectation is an example of transitivity: if a load executing on
+CPU~A follows a load from the same variable executing on CPU~B, then
+CPU~A's load must either return the same value that CPU~B's load did,
+or must return some later value.
+
+In the Linux kernel, use of general memory barriers guarantees
+transitivity.  Therefore, in the above example, if CPU~2's load from~\co{X}
+returns~1 and its load from~\co{Y} returns~0, then CPU~3's load from~\co{X} must
+also return~1.
+
+However, transitivity is {\em not} guaranteed for read or write barriers.
+For example, suppose that CPU~2's general barrier in the above example
+is changed to a read barrier as shown below with the same initial values of
+{\tt \{X = 0, Y = 0\}}:
+
+\vspace{5pt}
+\begin{minipage}[t]{\columnwidth}
+\tt
+\scriptsize
+\begin{tabular}{l|l|l}
+	\nf{CPU 1}	& \nf{CPU 2}		& \nf{CPU 3} \\
+	\hline
+	X = 1;		& LOAD X		& Y = 1; \\
+			& <read barrier>	& <general barrier> \\
+			& LOAD Y		& LOAD X \\
+\end{tabular}
+\end{minipage}
+\vspace{5pt}
+
+This substitution destroys transitivity: in this example, it is perfectly
+legal for CPU~2's load from~\co{X} to return~1, its load from~\co{Y} to return~0,
+and CPU~3's load from~\co{X} to return~0.
+
+The key point is that although CPU~2's read barrier orders its pair
+of loads, it does not guarantee to order CPU~1's store.  Therefore, if
+this example runs on a system where CPUs~1 and~2 share a store buffer
+or a level of cache, CPU~2 might have early access to CPU~1's writes.
+General barriers are therefore required to ensure that all CPUs agree
+on the combined order of CPU~1's and CPU~2's accesses.
+
+General barriers provide ``global transitivity'', so that all CPUs will
+agree on the order of operations.  In contrast, a chain of release-acquire
+pairs provides only ``local transitivity'', so that only those CPUs on
+the chain are guaranteed to agree on the combined order of the accesses.
+For example, switching to C code in deference to Herman Hollerith:
+
+{\scriptsize
+\begin{verbatim}
+   1 int u, v, x, y, z;
+   2
+   3 void cpu0(void)
+   4 {
+   5   r0 = smp_load_acquire(&x);
+   6   WRITE_ONCE(u, 1);
+   7   smp_store_release(&y, 1);
+   8 }
+   9
+  10 void cpu1(void)
+  11 {
+  12   r1 = smp_load_acquire(&y);
+  13   r4 = READ_ONCE(v);
+  14   r5 = READ_ONCE(u);
+  15   smp_store_release(&z, 1);
+  16 }
+  17
+  18 void cpu2(void)
+  19 {
+  20   r2 = smp_load_acquire(&z);
+  21   smp_store_release(&x, 1);
+  22 }
+  23
+  24 void cpu3(void)
+  25 {
+  26   WRITE_ONCE(v, 1);
+  27   smp_mb();
+  28   r3 = READ_ONCE(u);
+  29 }
+\end{verbatim}
+}
+
+Because \co{cpu0()}, \co{cpu1()}, and \co{cpu2()} participate in a local transitive
+chain of \co{smp_store_release()}-\co{smp_load_acquire()} pairs, the following
+outcome is prohibited:
+
+{\scriptsize
+\begin{verbatim}
+  r0 == 1 && r1 == 1 && r2 == 1
+\end{verbatim}
+}
+
+Furthermore, because of the release-acquire relationship between \co{cpu0()}
+and \co{cpu1()}, \co{cpu1()} must see \co{cpu0()}'s writes, so that the following
+outcome is prohibited:
+
+{\scriptsize
+\begin{verbatim}
+  r1 == 1 && r5 == 0
+\end{verbatim}
+}
+
+However, the transitivity of release-acquire is local to the participating
+CPUs and does not apply to \co{cpu3()}.  Therefore, the following outcome
+is possible:
+
+{\scriptsize
+\begin{verbatim}
+  r0 == 0 && r1 == 1 && r2 == 1 && r3 == 0 && r4 == 0
+\end{verbatim}
+}
+
+As an aside, the following outcome is also possible:
+
+{\scriptsize
+\begin{verbatim}
+  r0 == 0 && r1 == 1 && r2 == 1 && r3 == 0 && r4 == 0
+          && r5 == 1
+\end{verbatim}
+}
+
+Although \co{cpu0()}, \co{cpu1()}, and \co{cpu2()} will see their respective reads and
+writes in order, CPUs not involved in the release-acquire chain might
+well disagree on the order.  This disagreement stems from the fact that
+the weak memory-barrier instructions used to implement \co{smp_load_acquire()}
+and \co{smp_store_release()} are not required to order prior stores against
+subsequent loads in all cases.  This means that \co{cpu3()} can see \co{cpu0()}'s
+store to~\co{u} as happening {\em after} \co{cpu1()}'s load from~\co{v}, even though
+both \co{cpu0()} and \co{cpu1()} agree that these two operations occurred in the
+intended order.
+
+However, please keep in mind that \co{smp_load_acquire()} is not magic.
+In particular, it simply reads from its argument with ordering.  It does
+{\em not} ensure that any particular value will be read.  Therefore, the
+following outcome is possible:
+
+{\scriptsize
+\begin{verbatim}
+  r0 == 0 && r1 == 0 && r2 == 0 && r5 == 0
+\end{verbatim}
+}
+
+Note that this outcome can happen even on a mythical sequentially
+consistent system where nothing is ever reordered.
+
+To reiterate, if your code requires global transitivity, use general
+barriers throughout.
+
 \subsection{Locking Constraints}
 \label{sec:advsync:Locking Constraints}

-- 
2.7.4

[RFC PATCH 2/7] advsync: Permit p (page) placement for consecutive wide figures

[Akira Yokosawa]

From dca204da98e03f993098030fd6590b782a165690 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa <akiyks@gmail.com>
Date: Sat, 25 Mar 2017 17:42:38 +0900
Subject: [RFC PATCH 2/7] advsync: Permit p (page) placement for consecutive wide figures

In 2-column layouts, these figures tend to be placed far from where
it is referenced. It should be better to give room for LaTeX to
place these figures in dedicated pages.

In 1-column layouts, there is no visual change in the result.

Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
 advsync/memorybarriers.tex | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
index efc2cbd..496ace9 100644
--- a/advsync/memorybarriers.tex
+++ b/advsync/memorybarriers.tex
@@ -2287,7 +2287,7 @@ Without intervention, CPU~2 may perceive the events on CPU~1 in some
 effectively random order, despite the write barrier issued by CPU~1, as
 shown in Figure~\ref{fig:advsync:Data Dependency Barrier Omitted}.

-\begin{figure*}[htb]
+\begin{figure*}[htbp]
 \centering
 \includegraphics{advsync/DataDependencyNeeded}
 \caption{Data Dependency Barrier Omitted}
@@ -2323,7 +2323,7 @@ values of {\tt \{B = 7, X = 9, Y = 8, C = \&Y\}}:
 then ordering will be as intuitively expected, as shown in
 Figure~\ref{fig:advsync:Data Dependency Barrier Supplied}.

-\begin{figure*}[htb]
+\begin{figure*}[htbp]
 \centering
 \includegraphics{advsync/DataDependencySupplied}
 \caption{Data Dependency Barrier Supplied}
@@ -2354,7 +2354,7 @@ Without intervention, CPU~2 may then choose to perceive the events on CPU~1 in
 some effectively random order, despite the write barrier issued by CPU~1, as
 shown in Figure~\ref{fig:advsync:Read Barrier Needed}.

-\begin{figure*}[htb]
+\begin{figure*}[htbp]
 \centering
 \includegraphics{advsync/ReadBarrierNeeded}
 \caption{Read Barrier Needed}
@@ -2386,7 +2386,7 @@ then the partial ordering imposed by CPU~1's write barrier will be
 perceived correctly by CPU~2, as shown in
 Figure~\ref{fig:advsync:Read Barrier Supplied}.

-\begin{figure*}[htb]
+\begin{figure*}[htbp]
 \centering
 \includegraphics{advsync/ReadBarrierSupplied}
 \caption{Read Barrier Supplied}
@@ -2421,7 +2421,7 @@ both occur after the load of \co{B}, they may both
 come up with different values, as shown in
 Figure~\ref{fig:advsync:Read Barrier Supplied, Double Load}.

-\begin{figure*}[htb]
+\begin{figure*}[htbp]
 \centering
 \includegraphics{advsync/ReadBarrierSupplied1}
 \caption{Read Barrier Supplied, Double Load}
@@ -2432,7 +2432,7 @@ Of course, it may well be that CPU~1's update to \co{A} becomes perceptible
 to CPU~2 before the read barrier completes, as shown in
 Figure~\ref{fig:advsync:Read Barrier Supplied, Take Two}.

-\begin{figure*}[htb]
+\begin{figure*}[htbp]
 \centering
 \includegraphics{advsync/ReadBarrierSupplied2}
 \caption{Read Barrier Supplied, Take Two}
@@ -2486,7 +2486,7 @@ common case, overlapping the load with the divides will permit the load
 to complete more quickly, as illustrated by
 Figure~\ref{fig:advsync:Speculative Load}.

-\begin{figure*}[htb]
+\begin{figure*}[htbp]
 \centering
 \includegraphics{advsync/SpeculativeLoad}
 \caption{Speculative Load}
@@ -2522,14 +2522,14 @@ from some other CPU, then the speculation will be cancelled and the
 value of \co{A} will be reloaded,
 as shown in Figure~\ref{fig:advsync:Speculative Loads Cancelled by Barrier}.

-\begin{figure*}[htb]
+\begin{figure*}[htbp]
 \centering
 \includegraphics{advsync/SpeculativeLoadBarrier}
 \caption{Speculative Load and Barrier}
 \ContributedBy{Figure}{fig:advsync:Speculative Loads and Barrier}{David Howells}
 \end{figure*}

-\begin{figure*}[htb]
+\begin{figure*}[htbp]
 \centering
 \includegraphics{advsync/SpeculativeLoadBarrierCancel}
 \caption{Speculative Load Cancelled by Barrier}
-- 
2.7.4

[RFC PATCH 3/7] advsync: Make code snippet in deference to Herman Hollerith float

[Akira Yokosawa]

From a93a5669ea1a5200a59b255f33b32a77bfae8626 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa <akiyks@gmail.com>
Date: Sat, 25 Mar 2017 17:43:02 +0900
Subject: [RFC PATCH 3/7] advsync: Make code snippet in deference to Herman Hollerith float

Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
 advsync/memorybarriers.tex | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
index 496ace9..c26e931 100644
--- a/advsync/memorybarriers.tex
+++ b/advsync/memorybarriers.tex
@@ -2609,10 +2609,13 @@ General barriers provide ``global transitivity'', so that all CPUs will
 agree on the order of operations.  In contrast, a chain of release-acquire
 pairs provides only ``local transitivity'', so that only those CPUs on
 the chain are guaranteed to agree on the combined order of the accesses.
-For example, switching to C code in deference to Herman Hollerith:
+For example, switching to C~code in deference to Herman Hollerith shown in
+Figure~\ref{fig:advsync:Example of Local Transitivity (Release-Acquire Pair)}:

-{\scriptsize
-\begin{verbatim}
+\begin{figure}[htbp]
+\scriptsize
+\centering
+\begin{verbbox}
    1 int u, v, x, y, z;
    2
    3 void cpu0(void)
@@ -2642,8 +2645,11 @@ For example, switching to C code in deference to Herman Hollerith:
   27   smp_mb();
   28   r3 = READ_ONCE(u);
   29 }
-\end{verbatim}
-}
+\end{verbbox}
+\theverbbox
+\caption{Example of Local Transitivity (Release-Acquire Pair)}
+\label{fig:advsync:Example of Local Transitivity (Release-Acquire Pair)}
+\end{figure}

 Because \co{cpu0()}, \co{cpu1()}, and \co{cpu2()} participate in a local transitive
 chain of \co{smp_store_release()}-\co{smp_load_acquire()} pairs, the following
-- 
2.7.4

[RFC PATCH 4/7] advsync: Add footnote on transitivity

[Akira Yokosawa]

From dd1379033d25ea29bb922a5bafcd8366e18249ad Mon Sep 17 00:00:00 2001
From: Akira Yokosawa <akiyks@gmail.com>
Date: Sat, 25 Mar 2017 17:44:41 +0900
Subject: [RFC PATCH 4/7] advsync: Add footnote on transitivity

Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
 advsync/memorybarriers.tex | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
index c26e931..9b8c4c5 100644
--- a/advsync/memorybarriers.tex
+++ b/advsync/memorybarriers.tex
@@ -2162,7 +2162,9 @@ The following list of rules summarizes the lessons of this section:

 \item	Control dependencies pair normally with other types of barriers.

-\item	Control dependencies do \emph{not} provide transitivity.
+\item	Control dependencies do \emph{not} provide transitivity.\footnote{
+		Refer to Section~\ref{sec:advsync:Transitivity} for
+		the meaning of transitivity.}
 	If you need transitivity, use \co{smp_mb()}.
 \end{enumerate}

-- 
2.7.4

[RFC PATCH 5/7] advsync: Make code snippets more asm like

[Akira Yokosawa]

From eee8c456dd18cd262a88581acdba1082df6d5315 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa <akiyks@gmail.com>
Date: Sat, 25 Mar 2017 17:45:29 +0900
Subject: [RFC PATCH 5/7] advsync: Make code snippets more asm like

Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
 advsync/memorybarriers.tex | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
index 9b8c4c5..da464fd 100644
--- a/advsync/memorybarriers.tex
+++ b/advsync/memorybarriers.tex
@@ -2553,7 +2553,7 @@ demonstrates transitivity with initial values of
 \begin{tabular}{l|l|l}
 	\nf{CPU 1}	& \nf{CPU 2}		& \nf{CPU 3} \\
 	\hline
-	X = 1;		& LOAD X		& Y = 1; \\
+	STORE X = 1	& LOAD X		& STORE Y = 1 \\
 			& <general barrier>	& <general barrier> \\
 			& LOAD Y		& LOAD X \\
 \end{tabular}
@@ -2589,7 +2589,7 @@ is changed to a read barrier as shown below with the same initial values of
 \begin{tabular}{l|l|l}
 	\nf{CPU 1}	& \nf{CPU 2}		& \nf{CPU 3} \\
 	\hline
-	X = 1;		& LOAD X		& Y = 1; \\
+	STORE X = 1	& LOAD X		& STORE Y = 1 \\
 			& <read barrier>	& <general barrier> \\
 			& LOAD Y		& LOAD X \\
 \end{tabular}
-- 
2.7.4

[RFC PATCH 6/7] advsync: Properly use nbsp in initial values

[Akira Yokosawa]

From 5491d5d9aad320ba08b304bea3085cc0a02c9390 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa <akiyks@gmail.com>
Date: Sat, 25 Mar 2017 17:46:04 +0900
Subject: [RFC PATCH 6/7] advsync: Properly use nbsp in initial values

Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
 advsync/memorybarriers.tex | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
index da464fd..b6665b6 100644
--- a/advsync/memorybarriers.tex
+++ b/advsync/memorybarriers.tex
@@ -2544,7 +2544,7 @@ as shown in Figure~\ref{fig:advsync:Speculative Loads Cancelled by Barrier}.
 ``Transitivity'' is a deeply intuitive notion about ordering that is not
 always provided by real computer systems.  The following example
 demonstrates transitivity with initial values of
-{\tt \{X = 0, Y = 0\}}:
+{\tt \{X~=~0, Y~=~0\}}:

 \vspace{5pt}
 \begin{minipage}[t]{\columnwidth}
@@ -2580,7 +2580,7 @@ also return~1.
 However, transitivity is {\em not} guaranteed for read or write barriers.
 For example, suppose that CPU~2's general barrier in the above example
 is changed to a read barrier as shown below with the same initial values of
-{\tt \{X = 0, Y = 0\}}:
+{\tt \{X~=~0, Y~=~0\}}:

 \vspace{5pt}
 \begin{minipage}[t]{\columnwidth}
-- 
2.7.4

[RFC PATCH 7/7] advsync: Avoid indent after minipage

[Akira Yokosawa]

From 461f7d8b71f955c17ce30585b301834c3ad4026b Mon Sep 17 00:00:00 2001
From: Akira Yokosawa <akiyks@gmail.com>
Date: Sat, 25 Mar 2017 17:46:27 +0900
Subject: [RFC PATCH 7/7] advsync: Avoid indent after minipage

Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
 advsync/memorybarriers.tex | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/advsync/memorybarriers.tex b/advsync/memorybarriers.tex
index b6665b6..165b5cb 100644
--- a/advsync/memorybarriers.tex
+++ b/advsync/memorybarriers.tex
@@ -2511,9 +2511,9 @@ load:
 		&	<read barrier> \\
 		&	LOAD A \\
 \end{tabular}
-\end{minipage}
 \vspace{5pt}
-
+\end{minipage}
+%
 will force any value speculatively obtained to be reconsidered to an extent
 dependent on the type of barrier used.  If there was no change made to the
 speculated memory location, then the speculated value will just be used,
-- 
2.7.4

Re: [RFC PATCH 0/7] Import 'TRANSITIVITY' section

[Paul E. McKenney]

On Sat, Mar 25, 2017 at 06:33:55PM +0900, Akira Yokosawa wrote:
> >From 461f7d8b71f955c17ce30585b301834c3ad4026b Mon Sep 17 00:00:00 2001
> From: Akira Yokosawa <akiyks@gmail.com>
> Date: Sat, 25 Mar 2017 17:54:01 +0900
> Subject: [RFC PATCH 0/7] Import 'TRANSITIVITY' section
> 
> Hi Paul,
> 
> As has been being discussed off the list, I'm attempting to update
> "Memory Barriers" section to catch up memory-barriers.txt.
> 
> This patch set imports "TRANSITIVITY" section and do some tweaks
> for better LaTeX typesetting.
> 
> Patch 1 imports the section mostly as is.
> Patch 5 diverts from current memory-barriers.txt in the way to
> present code snippets.
> Patches 2 and 7 are updates for issues in previous sections I noticed
> while doing this work.
> 
> Although we need further updates, especially to replace "LOCK/UNLOCK"
> with "ACQUIRE/RELEASE" to go along with changes in memory-barriers.txt,
> this patch set seems worthy on its own.

Queued and pushed, thank you!

							Thanx, Paul

> Thoughts?
>                                   Thanks, Akira
> --
> 
> Akira Yokosawa (7):
>   advsync: Import 'TRANSITIVITY' section from memory-barriers.txt
>   advsync: Permit p (page) placement for consecutive wide figures
>   advsync: Make code snippet in deference to Herman Hollerith float
>   advsync: Add footnote on transitivity
>   advsync: Make code snippets more asm like
>   advsync: Properly use nbsp in initial values
>   advsync: Avoid indent after minipage
> 
>  advsync/memorybarriers.tex | 207 ++++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 195 insertions(+), 12 deletions(-)
> 
> -- 
> 2.7.4
>