From 11a65df5732167519937eabf16a870f5f8bde5ee Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Tue, 15 Mar 2016 11:03:36 -0700 Subject: documentation: Remove unnecessary images from requirements This commit removes a cutesy cartoon and also a diagram that can just as easily be represented by text. Reported-by: Linus Torvalds Signed-off-by: Paul E. McKenney --- .../RCU/Design/Requirements/2013-08-is-it-dead.png | Bin 100825 -> 0 bytes .../RCU/Design/Requirements/RCUApplicability.svg | 237 --------------------- .../RCU/Design/Requirements/Requirements.html | 28 ++- .../RCU/Design/Requirements/Requirements.htmlx | 28 ++- 4 files changed, 40 insertions(+), 253 deletions(-) delete mode 100644 Documentation/RCU/Design/Requirements/2013-08-is-it-dead.png delete mode 100644 Documentation/RCU/Design/Requirements/RCUApplicability.svg (limited to 'Documentation/RCU') diff --git a/Documentation/RCU/Design/Requirements/2013-08-is-it-dead.png b/Documentation/RCU/Design/Requirements/2013-08-is-it-dead.png deleted file mode 100644 index 7496a55e4e7b..000000000000 Binary files a/Documentation/RCU/Design/Requirements/2013-08-is-it-dead.png and /dev/null differ diff --git a/Documentation/RCU/Design/Requirements/RCUApplicability.svg b/Documentation/RCU/Design/Requirements/RCUApplicability.svg deleted file mode 100644 index ebcbeee391ed..000000000000 --- a/Documentation/RCU/Design/Requirements/RCUApplicability.svg +++ /dev/null @@ -1,237 +0,0 @@ - - - - - - - - - - - - image/svg+xml - - - - - - - - - - - - - - - - - - Read-Mostly, Stale & - - Inconsistent Data OK - - (RCU Works Great!!!) - - (RCU Works Well) - - Read-Mostly, Need Consistent Data - - Read-Write, Need Consistent Data - - Update-Mostly, Need Consistent Data - - (RCU Might Be OK...) - - (1) Provide Existence Guarantees For Update-Friendly Mechanisms - - (2) Provide Wait-Free Read-Side Primitives for Real-Time Use) - - (RCU is Very Unlikely to be the Right Tool For The Job, But it Can: - - diff --git a/Documentation/RCU/Design/Requirements/Requirements.html b/Documentation/RCU/Design/Requirements/Requirements.html index 01e12b86e81f..c67a96a2a389 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.html +++ b/Documentation/RCU/Design/Requirements/Requirements.html @@ -1120,12 +1120,27 @@ These classes is covered in the following sections.

Specialization

-RCU is and always has been intended primarily for read-mostly situations, as -illustrated by the following figure. -This means that RCU's read-side primitives are optimized, often at the +RCU is and always has been intended primarily for read-mostly situations, +which means that RCU's read-side primitives are optimized, often at the expense of its update-side primitives. +Experience thus far is captured by the following list of situations: -

RCUApplicability.svg

+
    +
  1. Read-mostly data, where stale and inconsistent data is not + a problem: RCU works great! +
  2. Read-mostly data, where data must be consistent: + RCU works well. +
  3. Read-write data, where data must be consistent: + RCU might work OK. + Or not. +
  4. Write-mostly data, where data must be consistent: + RCU is very unlikely to be the right tool for the job, + with the following exceptions, where RCU can provide: +
      +
    1. Existence guarantees for update-friendly mechanisms. +
    2. Wait-free read-side primitives for real-time use. +
    +

This focus on read-mostly situations means that RCU must interoperate @@ -1171,10 +1186,7 @@ some period of time, so the exact wait period is a judgment call. One of our pair of veternarians might wait 30 seconds before pronouncing the cat dead, while the other might insist on waiting a full minute. The two veternarians would then disagree on the state of the cat during -the final 30 seconds of the minute following the last heartbeat, as -fancifully illustrated below: - -

2013-08-is-it-dead.png

+the final 30 seconds of the minute following the last heartbeat.

Interestingly enough, this same situation applies to hardware. diff --git a/Documentation/RCU/Design/Requirements/Requirements.htmlx b/Documentation/RCU/Design/Requirements/Requirements.htmlx index 3355f1f9384c..d6a84f3e0451 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.htmlx +++ b/Documentation/RCU/Design/Requirements/Requirements.htmlx @@ -1257,12 +1257,27 @@ These classes is covered in the following sections.

Specialization

-RCU is and always has been intended primarily for read-mostly situations, as -illustrated by the following figure. -This means that RCU's read-side primitives are optimized, often at the +RCU is and always has been intended primarily for read-mostly situations, +which means that RCU's read-side primitives are optimized, often at the expense of its update-side primitives. +Experience thus far is captured by the following list of situations: -

RCUApplicability.svg

+
    +
  1. Read-mostly data, where stale and inconsistent data is not + a problem: RCU works great! +
  2. Read-mostly data, where data must be consistent: + RCU works well. +
  3. Read-write data, where data must be consistent: + RCU might work OK. + Or not. +
  4. Write-mostly data, where data must be consistent: + RCU is very unlikely to be the right tool for the job, + with the following exceptions, where RCU can provide: +
      +
    1. Existence guarantees for update-friendly mechanisms. +
    2. Wait-free read-side primitives for real-time use. +
    +

This focus on read-mostly situations means that RCU must interoperate @@ -1330,10 +1345,7 @@ some period of time, so the exact wait period is a judgment call. One of our pair of veternarians might wait 30 seconds before pronouncing the cat dead, while the other might insist on waiting a full minute. The two veternarians would then disagree on the state of the cat during -the final 30 seconds of the minute following the last heartbeat, as -fancifully illustrated below: - -

2013-08-is-it-dead.png

+the final 30 seconds of the minute following the last heartbeat.

Interestingly enough, this same situation applies to hardware. -- cgit v1.2.3