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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>From dca204da98e03f993098030fd6590b782a165690 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa <akiyks@xxxxxxxxx>
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@xxxxxxxxx>
---
 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


--
To unsubscribe from this list: send the line "unsubscribe perfbook" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux