All of lore.kernel.org
 help / color / mirror / Atom feed
From: Akira Yokosawa <akiyks@gmail.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: perfbook@vger.kernel.org, Akira Yokosawa <akiyks@gmail.com>
Subject: Re: [RFC PATCH v2 0/2] CodeSamples: Cleanups and fixes
Date: Thu, 1 Jun 2017 06:19:16 +0900	[thread overview]
Message-ID: <907f9e98-05b5-ab60-c854-e19deab39629@gmail.com> (raw)
In-Reply-To: <20170531184655.GR3956@linux.vnet.ibm.com>

On 2017/05/31 11:46:55 -0700, Paul E. McKenney wrote:
> On Tue, May 30, 2017 at 09:05:15PM +0900, Akira Yokosawa wrote:
>> >From 489b5e3bdeba2f9b733dbe3d85390368dd159174 Mon Sep 17 00:00:00 2001
>> From: Akira Yokosawa <akiyks@gmail.com>
>> Date: Tue, 30 May 2017 20:44:52 +0900
>> Subject: [RFC PATCH v2 0/2] CodeSamples: Cleanups and fixes
>>
>> Hi Paul,
>>
>> This is the respin of the latter two patches of v1. I'm keeping RFC
>> because of some questions.
>>
>> "long" -> "intptr_t" changes in Patch 1 have no effect on a platform
>> where "long" and "intptr_t" have the same width, but I think they
>> are good in portability POV.
>>
>> WRITE_ONCE() in Patch 2 is placed under the assignment to the array
>> because I could not translate post increment in any other way.
>> Does the WRITE_ONCE() ensure the outer "while" capture the value?
> 
> Wow, that loop is old code!!!  My current compiler creates an infinite
> loop for it, so yes, there is more required.

You mean on GCC for ppc64?

>                                               Plus there are confusing
> and redundant comparisons, so that it is not entirely clear to me that
> the loop is guaranteed to terminate properly
> 
> So I took both patches, but rewrote the loop in the second patch as
> shown below.
> 
> If you are OK with this rewrite, I will push them.

I'm OK with this, but it is a whole rewrite of the code, so

Reported-by: Akira Yokosawa <akiyks@gmail.com>

looks appropriate in this case.
It's up to you which tag to use.

                  Thanks, Akira

> 
> 							Thanx, Paul
> 
> ------------------------------------------------------------------------
> 
> commit 8a54d9aeeeefa1909db062dc893705ff8fefd702
> Author: Akira Yokosawa <akiyks@gmail.com>
> Date:   Tue May 30 20:40:04 2017 +0900
> 
>     CodeSamples/defer: Rework loop in gettimestampmp.c
>     
>     Add READ_ONCE() and WRITE_ONCE() ensure curtimestamp is read and written
>     once in every iteration.  The READ_ONCE() is not optional, as modern
>     compilers can (and do) emit an infinite loop for the earlier code.
>     
>     Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
>     [ paulmck: Rework loop to eliminate redundant fetches and comparisons. ]
>     Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> 
> diff --git a/CodeSamples/defer/gettimestampmp.c b/CodeSamples/defer/gettimestampmp.c
> index 2abade42e233..8780b71f33d7 100644
> --- a/CodeSamples/defer/gettimestampmp.c
> +++ b/CodeSamples/defer/gettimestampmp.c
> @@ -30,16 +30,19 @@ long curtimestamp = 0;
>  void *collect_timestamps(void *mask_in)
>  {
>  	long mask = (intptr_t)mask_in;
> +	long cts;
>  
> -	while (curtimestamp < MAX_TIMESTAMPS) {
> -		while ((curtimestamp & CURTIMESTAMP_MASK) != mask)
> -			continue;
> -		if (curtimestamp >= MAX_TIMESTAMPS)
> +	for (;;) {
> +		cts = READ_ONCE(curtimestamp);
> +		if (cts >= MAX_TIMESTAMPS)
>  			break;
> +		if ((cts & CURTIMESTAMP_MASK) != mask)
> +			continue;
>  
>  		/* Don't need memory barrier -- no other shared vars!!! */
>  
> -		ts[curtimestamp++] = get_timestamp();
> +		ts[cts] = get_timestamp();
> +		WRITE_ONCE(curtimestamp, cts + 1);
>  	}
>  	smp_mb();
>  	return (NULL);
> 
> 


  reply	other threads:[~2017-05-31 21:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-29 22:13 [RFC PATCH 0/4] CodeSamples: Cleanups and fixes Akira Yokosawa
2017-05-29 22:14 ` [RFC PATCH 1/4] CodeSamples: Add rule to generate Makefile.arch and api.h Akira Yokosawa
2017-05-29 22:16 ` [RFC PATCH 2/4] CodeSamples: Remove generated files from repository Akira Yokosawa
2017-05-29 22:17 ` [RFC PATCH 3/4] CodeSamples: Use 'intptr_t' to be compatible with 'void *' Akira Yokosawa
2017-05-30  0:10   ` Paul E. McKenney
2017-05-29 22:18 ` [RFC PATCH 4/4] CodeSamples/defer: Add compiler barriers in gettimestampmp.c Akira Yokosawa
2017-05-30  0:12   ` Paul E. McKenney
2017-05-30  0:02 ` [RFC PATCH 0/4] CodeSamples: Cleanups and fixes Paul E. McKenney
2017-05-30  1:44   ` Akira Yokosawa
2017-05-30 12:05 ` [RFC PATCH v2 0/2] " Akira Yokosawa
2017-05-30 12:06   ` [RFC PATCH v2 1/2] CodeSamples: Use 'intptr_t' to be compatible with 'void *' Akira Yokosawa
2017-05-30 12:07   ` [RFC PATCH v2 2/2] CodeSamples/defer: Add compiler barriers in gettimestampmp.c Akira Yokosawa
2017-05-31 18:46   ` [RFC PATCH v2 0/2] CodeSamples: Cleanups and fixes Paul E. McKenney
2017-05-31 21:19     ` Akira Yokosawa [this message]
2017-06-01  0:05       ` Paul E. McKenney
2017-06-01  1:45     ` Junchang Wang
2017-06-01  4:19       ` Paul E. McKenney
2017-06-01  4:34         ` Junchang Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=907f9e98-05b5-ab60-c854-e19deab39629@gmail.com \
    --to=akiyks@gmail.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=perfbook@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.