From: Junchang Wang <junchangwang@gmail.com>
To: perfbook@vger.kernel.org, paulmck@linux.vnet.ibm.com
Cc: Junchang Wang <junchangwang@gmail.com>
Subject: [PATCH 0/2] Patches to chapter Deferred Processing
Date: Thu, 8 Jun 2017 11:16:31 +0800 [thread overview]
Message-ID: <1496891793-5755-1-git-send-email-junchangwang@gmail.com> (raw)
Hi Paul and list,
Attached are two patches for routetorture.h. Please take a look.
One of my remaining question is about the two smp_mb() in routetorture.h. Take
the smp_mb() in perftest() as example, my understanding is that it is used to
prevent the access to nthreads_running and access to goflag from being
reorganized. If that's the case, don't we need a paired memory barrier
instruction in perftest_reader()? Specifically, in between line 105
(atomic_inc(&nthreads_running);) and line 106 (gf = READ_ONCE(goflag);).
Another puzzle is that we are using shared memory 'pap' to transfer statistic
results from working threads, e.g. perftest_reader, to main thread, e.g.
perftest. Do we need a smp_mb() at the tail (before instruction return) of
function perftest_reader to force the results being written before the thread
terminates? In other words, I'm not sure if the two events, writing to shared
memory pap and thread termination, could be reordered. Hints are welcome!
Thanks,
--Jason
Junchang Wang (2):
Fix typos in help messages
routetorture.h: Switch from ACCESS_ONCE() to READ_ONCE()/WRITE_ONCE()
CodeSamples/defer/routetorture.h | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--
2.7.4
next reply other threads:[~2017-06-08 3:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-08 3:16 Junchang Wang [this message]
2017-06-08 3:16 ` [PATCH 1/2] routetorture.h: Fix typos in help messages Junchang Wang
2017-06-08 3:16 ` [PATCH 2/2] routetorture.h: Switch from ACCESS_ONCE() to READ_ONCE()/WRITE_ONCE() Junchang Wang
2017-06-08 3:38 ` [PATCH 0/2] Patches to chapter Deferred Processing Paul E. McKenney
2017-06-08 4:30 ` 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=1496891793-5755-1-git-send-email-junchangwang@gmail.com \
--to=junchangwang@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.