Re: [PATCH tip/core/rcu 1/2] documentation: Present updated RCU guarantee

[Paul E. McKenney]

On Mon, Nov 14, 2016 at 11:57:46AM -0500, Pranith Kumar wrote:
> Hi Paul,
> 
> On Mon, Nov 14, 2016 at 11:47 AM, Paul E. McKenney
>  wrote:
> > Recent memory-model work deduces the relationships of RCU read-side
> > critical sections and grace periods based on the relationships of
> > accesses within a critical section and accesses preceding and following
> > the grace period.  This commit therefore adds this viewpoint.
> >
> > Signed-off-by: Paul E. McKenney 
> > ---
> >  .../RCU/Design/Requirements/Requirements.html  | 25 
> > +-
> >  1 file changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/RCU/Design/Requirements/Requirements.html 
> > b/Documentation/RCU/Design/Requirements/Requirements.html
> > index a4d3838130e4..81b40cb83435 100644
> > --- a/Documentation/RCU/Design/Requirements/Requirements.html
> > +++ b/Documentation/RCU/Design/Requirements/Requirements.html
> > @@ -547,7 +547,7 @@ The rcu_access_pointer() on line6 is 
> > similar to
> > It could reuse a value formerly fetched from this same pointer.
> > It could also fetch the pointer from gp in a byte-at-a-time
> > manner, resulting in load tearing, in turn resulting a 
> > bytewise
> > -   mash-up of two distince pointer values.
> > +   mash-up of two distinct pointer values.
> > It might even use value-speculation optimizations, where it makes
> > a wrong guess, but by the time it gets around to checking the
> > value, an update has changed the pointer to match the wrong guess.
> > @@ -659,6 +659,29 @@ systems with more than one CPU:
> > In other words, a given instance of synchronize_rcu()
> > can avoid waiting on a given RCU read-side critical section only
> > if it can prove that synchronize_rcu() started first.
> > +
> > +   
> > +   A related question is When rcu_read_lock()
> > +   doesn't generate any code, why does it matter how it relates
> > +   to a grace period?
> > +   The answer if that it is not the relationship of
> 
> s/if/is?

Good catch, fixed!

Thanx, Paul

> > +   rcu_read_lock() itself that is important, but rather
> > +   the relationship of the code within the enclosed RCU read-side
> > +   critical section to the code preceding and following the
> > +   grace period.
> > +   If we take this viewpoint, then a given RCU read-side critical
> > +   section begins before a given grace period when some access
> > +   preceding the grace period observes the effect of some access
> > +   within the critical section, in which case none of the accesses
> > +   within the critical section may observe the effects of any
> > +   access following the grace period.
> > +
> > +   
> > +   As of late 2016, mathematical models of RCU take this
> > +   viewpoint, for example, see slides62 and63
> > +   of the
> > +> href="http://www2.rdrop.com/users/paulmck/scalability/paper/LinuxMM.2016.10.04c.LCE.pdf;>2016
> >  LinuxCon EU
> > +   presentation.
> >  
> >  
> >  
> > --
> > 2.5.2
> >
> 
> 
> 
> -- 
> Pranith
> 

Re: [PATCH tip/core/rcu 1/2] documentation: Present updated RCU guarantee

[Paul E. McKenney]

On Mon, Nov 14, 2016 at 11:57:46AM -0500, Pranith Kumar wrote:
> Hi Paul,
> 
> On Mon, Nov 14, 2016 at 11:47 AM, Paul E. McKenney
>  wrote:
> > Recent memory-model work deduces the relationships of RCU read-side
> > critical sections and grace periods based on the relationships of
> > accesses within a critical section and accesses preceding and following
> > the grace period.  This commit therefore adds this viewpoint.
> >
> > Signed-off-by: Paul E. McKenney 
> > ---
> >  .../RCU/Design/Requirements/Requirements.html  | 25 
> > +-
> >  1 file changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/RCU/Design/Requirements/Requirements.html 
> > b/Documentation/RCU/Design/Requirements/Requirements.html
> > index a4d3838130e4..81b40cb83435 100644
> > --- a/Documentation/RCU/Design/Requirements/Requirements.html
> > +++ b/Documentation/RCU/Design/Requirements/Requirements.html
> > @@ -547,7 +547,7 @@ The rcu_access_pointer() on line6 is 
> > similar to
> > It could reuse a value formerly fetched from this same pointer.
> > It could also fetch the pointer from gp in a byte-at-a-time
> > manner, resulting in load tearing, in turn resulting a 
> > bytewise
> > -   mash-up of two distince pointer values.
> > +   mash-up of two distinct pointer values.
> > It might even use value-speculation optimizations, where it makes
> > a wrong guess, but by the time it gets around to checking the
> > value, an update has changed the pointer to match the wrong guess.
> > @@ -659,6 +659,29 @@ systems with more than one CPU:
> > In other words, a given instance of synchronize_rcu()
> > can avoid waiting on a given RCU read-side critical section only
> > if it can prove that synchronize_rcu() started first.
> > +
> > +   
> > +   A related question is When rcu_read_lock()
> > +   doesn't generate any code, why does it matter how it relates
> > +   to a grace period?
> > +   The answer if that it is not the relationship of
> 
> s/if/is?

Good catch, fixed!

Thanx, Paul

> > +   rcu_read_lock() itself that is important, but rather
> > +   the relationship of the code within the enclosed RCU read-side
> > +   critical section to the code preceding and following the
> > +   grace period.
> > +   If we take this viewpoint, then a given RCU read-side critical
> > +   section begins before a given grace period when some access
> > +   preceding the grace period observes the effect of some access
> > +   within the critical section, in which case none of the accesses
> > +   within the critical section may observe the effects of any
> > +   access following the grace period.
> > +
> > +   
> > +   As of late 2016, mathematical models of RCU take this
> > +   viewpoint, for example, see slides62 and63
> > +   of the
> > +> href="http://www2.rdrop.com/users/paulmck/scalability/paper/LinuxMM.2016.10.04c.LCE.pdf;>2016
> >  LinuxCon EU
> > +   presentation.
> >  
> >  
> >  
> > --
> > 2.5.2
> >
> 
> 
> 
> -- 
> Pranith
> 

Re: [PATCH tip/core/rcu 1/2] documentation: Present updated RCU guarantee

[Pranith Kumar]

Hi Paul,

On Mon, Nov 14, 2016 at 11:47 AM, Paul E. McKenney
 wrote:
> Recent memory-model work deduces the relationships of RCU read-side
> critical sections and grace periods based on the relationships of
> accesses within a critical section and accesses preceding and following
> the grace period.  This commit therefore adds this viewpoint.
>
> Signed-off-by: Paul E. McKenney 
> ---
>  .../RCU/Design/Requirements/Requirements.html  | 25 
> +-
>  1 file changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/RCU/Design/Requirements/Requirements.html 
> b/Documentation/RCU/Design/Requirements/Requirements.html
> index a4d3838130e4..81b40cb83435 100644
> --- a/Documentation/RCU/Design/Requirements/Requirements.html
> +++ b/Documentation/RCU/Design/Requirements/Requirements.html
> @@ -547,7 +547,7 @@ The rcu_access_pointer() on line6 is 
> similar to
> It could reuse a value formerly fetched from this same pointer.
> It could also fetch the pointer from gp in a byte-at-a-time
> manner, resulting in load tearing, in turn resulting a bytewise
> -   mash-up of two distince pointer values.
> +   mash-up of two distinct pointer values.
> It might even use value-speculation optimizations, where it makes
> a wrong guess, but by the time it gets around to checking the
> value, an update has changed the pointer to match the wrong guess.
> @@ -659,6 +659,29 @@ systems with more than one CPU:
> In other words, a given instance of synchronize_rcu()
> can avoid waiting on a given RCU read-side critical section only
> if it can prove that synchronize_rcu() started first.
> +
> +   
> +   A related question is When rcu_read_lock()
> +   doesn't generate any code, why does it matter how it relates
> +   to a grace period?
> +   The answer if that it is not the relationship of

s/if/is?

> +   rcu_read_lock() itself that is important, but rather
> +   the relationship of the code within the enclosed RCU read-side
> +   critical section to the code preceding and following the
> +   grace period.
> +   If we take this viewpoint, then a given RCU read-side critical
> +   section begins before a given grace period when some access
> +   preceding the grace period observes the effect of some access
> +   within the critical section, in which case none of the accesses
> +   within the critical section may observe the effects of any
> +   access following the grace period.
> +
> +   
> +   As of late 2016, mathematical models of RCU take this
> +   viewpoint, for example, see slides62 and63
> +   of the
> +href="http://www2.rdrop.com/users/paulmck/scalability/paper/LinuxMM.2016.10.04c.LCE.pdf;>2016
>  LinuxCon EU
> +   presentation.
>  
>  
>  
> --
> 2.5.2
>



-- 
Pranith

Re: [PATCH tip/core/rcu 1/2] documentation: Present updated RCU guarantee

[Pranith Kumar]

Hi Paul,

On Mon, Nov 14, 2016 at 11:47 AM, Paul E. McKenney
 wrote:
> Recent memory-model work deduces the relationships of RCU read-side
> critical sections and grace periods based on the relationships of
> accesses within a critical section and accesses preceding and following
> the grace period.  This commit therefore adds this viewpoint.
>
> Signed-off-by: Paul E. McKenney 
> ---
>  .../RCU/Design/Requirements/Requirements.html  | 25 
> +-
>  1 file changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/RCU/Design/Requirements/Requirements.html 
> b/Documentation/RCU/Design/Requirements/Requirements.html
> index a4d3838130e4..81b40cb83435 100644
> --- a/Documentation/RCU/Design/Requirements/Requirements.html
> +++ b/Documentation/RCU/Design/Requirements/Requirements.html
> @@ -547,7 +547,7 @@ The rcu_access_pointer() on line6 is 
> similar to
> It could reuse a value formerly fetched from this same pointer.
> It could also fetch the pointer from gp in a byte-at-a-time
> manner, resulting in load tearing, in turn resulting a bytewise
> -   mash-up of two distince pointer values.
> +   mash-up of two distinct pointer values.
> It might even use value-speculation optimizations, where it makes
> a wrong guess, but by the time it gets around to checking the
> value, an update has changed the pointer to match the wrong guess.
> @@ -659,6 +659,29 @@ systems with more than one CPU:
> In other words, a given instance of synchronize_rcu()
> can avoid waiting on a given RCU read-side critical section only
> if it can prove that synchronize_rcu() started first.
> +
> +   
> +   A related question is When rcu_read_lock()
> +   doesn't generate any code, why does it matter how it relates
> +   to a grace period?
> +   The answer if that it is not the relationship of

s/if/is?

> +   rcu_read_lock() itself that is important, but rather
> +   the relationship of the code within the enclosed RCU read-side
> +   critical section to the code preceding and following the
> +   grace period.
> +   If we take this viewpoint, then a given RCU read-side critical
> +   section begins before a given grace period when some access
> +   preceding the grace period observes the effect of some access
> +   within the critical section, in which case none of the accesses
> +   within the critical section may observe the effects of any
> +   access following the grace period.
> +
> +   
> +   As of late 2016, mathematical models of RCU take this
> +   viewpoint, for example, see slides62 and63
> +   of the
> +href="http://www2.rdrop.com/users/paulmck/scalability/paper/LinuxMM.2016.10.04c.LCE.pdf;>2016
>  LinuxCon EU
> +   presentation.
>  
>  
>  
> --
> 2.5.2
>



-- 
Pranith

[PATCH tip/core/rcu 1/2] documentation: Present updated RCU guarantee

[Paul E. McKenney]

Recent memory-model work deduces the relationships of RCU read-side
critical sections and grace periods based on the relationships of
accesses within a critical section and accesses preceding and following
the grace period.  This commit therefore adds this viewpoint.

Signed-off-by: Paul E. McKenney 
---
 .../RCU/Design/Requirements/Requirements.html  | 25 +-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/Documentation/RCU/Design/Requirements/Requirements.html 
b/Documentation/RCU/Design/Requirements/Requirements.html
index a4d3838130e4..81b40cb83435 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.html
+++ b/Documentation/RCU/Design/Requirements/Requirements.html
@@ -547,7 +547,7 @@ The rcu_access_pointer() on line6 is similar 
to
It could reuse a value formerly fetched from this same pointer.
It could also fetch the pointer from gp in a byte-at-a-time
manner, resulting in load tearing, in turn resulting a bytewise
-   mash-up of two distince pointer values.
+   mash-up of two distinct pointer values.
It might even use value-speculation optimizations, where it makes
a wrong guess, but by the time it gets around to checking the
value, an update has changed the pointer to match the wrong guess.
@@ -659,6 +659,29 @@ systems with more than one CPU:
In other words, a given instance of synchronize_rcu()
can avoid waiting on a given RCU read-side critical section only
if it can prove that synchronize_rcu() started first.
+
+   
+   A related question is When rcu_read_lock()
+   doesn't generate any code, why does it matter how it relates
+   to a grace period?
+   The answer if that it is not the relationship of
+   rcu_read_lock() itself that is important, but rather
+   the relationship of the code within the enclosed RCU read-side
+   critical section to the code preceding and following the
+   grace period.
+   If we take this viewpoint, then a given RCU read-side critical
+   section begins before a given grace period when some access
+   preceding the grace period observes the effect of some access
+   within the critical section, in which case none of the accesses
+   within the critical section may observe the effects of any
+   access following the grace period.
+
+   
+   As of late 2016, mathematical models of RCU take this
+   viewpoint, for example, see slides62 and63
+   of the
+   http://www2.rdrop.com/users/paulmck/scalability/paper/LinuxMM.2016.10.04c.LCE.pdf;>2016
 LinuxCon EU
+   presentation.
 
 
 
-- 
2.5.2

[PATCH tip/core/rcu 1/2] documentation: Present updated RCU guarantee

[Paul E. McKenney]

Recent memory-model work deduces the relationships of RCU read-side
critical sections and grace periods based on the relationships of
accesses within a critical section and accesses preceding and following
the grace period.  This commit therefore adds this viewpoint.

Signed-off-by: Paul E. McKenney 
---
 .../RCU/Design/Requirements/Requirements.html  | 25 +-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/Documentation/RCU/Design/Requirements/Requirements.html 
b/Documentation/RCU/Design/Requirements/Requirements.html
index a4d3838130e4..81b40cb83435 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.html
+++ b/Documentation/RCU/Design/Requirements/Requirements.html
@@ -547,7 +547,7 @@ The rcu_access_pointer() on line6 is similar 
to
It could reuse a value formerly fetched from this same pointer.
It could also fetch the pointer from gp in a byte-at-a-time
manner, resulting in load tearing, in turn resulting a bytewise
-   mash-up of two distince pointer values.
+   mash-up of two distinct pointer values.
It might even use value-speculation optimizations, where it makes
a wrong guess, but by the time it gets around to checking the
value, an update has changed the pointer to match the wrong guess.
@@ -659,6 +659,29 @@ systems with more than one CPU:
In other words, a given instance of synchronize_rcu()
can avoid waiting on a given RCU read-side critical section only
if it can prove that synchronize_rcu() started first.
+
+   
+   A related question is When rcu_read_lock()
+   doesn't generate any code, why does it matter how it relates
+   to a grace period?
+   The answer if that it is not the relationship of
+   rcu_read_lock() itself that is important, but rather
+   the relationship of the code within the enclosed RCU read-side
+   critical section to the code preceding and following the
+   grace period.
+   If we take this viewpoint, then a given RCU read-side critical
+   section begins before a given grace period when some access
+   preceding the grace period observes the effect of some access
+   within the critical section, in which case none of the accesses
+   within the critical section may observe the effects of any
+   access following the grace period.
+
+   
+   As of late 2016, mathematical models of RCU take this
+   viewpoint, for example, see slides62 and63
+   of the
+   http://www2.rdrop.com/users/paulmck/scalability/paper/LinuxMM.2016.10.04c.LCE.pdf;>2016
 LinuxCon EU
+   presentation.
 
 
 
-- 
2.5.2