On 2018/12/26 07:00:19 -0800, Paul E. McKenney wrote:
> On Wed, Dec 26, 2018 at 11:31:03PM +0900, Akira Yokosawa wrote:
>> >From 6c0e6e632bbf234de340bcf51acf2007d8e3ac8b Mon Sep 17 00:00:00 2001
>> From: Akira Yokosawa <akiyks@xxxxxxxxx>
>> Date: Wed, 26 Dec 2018 23:11:26 +0900
>> Subject: [PATCH] gen_snippet_d.pl: Add rules to ignore editor's backup files
>>
>> Excerpt from Paul's report:
>> $ make
>> sh ./utilities/gen_snippet_d.sh
>> sh utilities/autodate.sh >autodate.tex
>> CodeSamples/datastruct/hash/hash_resize.c --> CodeSamples/datastruct/hash/hash_resize@xxxxxxxx
>> [...]
>> CodeSamples/datastruct/hash/.hash_resize.c.swp --> CodeSamples/datastruct/hash/CodeSamples/datastruct/hash.fcv
>> utilities/fcvextract.pl CodeSamples/datastruct/hash/.hash_resize.c.swp hash > CodeSamples/datastruct/hash/CodeSamples/datastruct/hash.fcv
>> /bin/bash: CodeSamples/datastruct/hash/CodeSamples/datastruct/hash.fcv: No such file or directory
>> make: *** [CodeSamples/datastruct/hash/CodeSamples/datastruct/hash.fcv] Error 1
>>
>> .hash_resize.c.swp is a swap file of vim, which causes an invalid
>> dependency rule to be emitted.
>>
>> To prevent such errors, ignore .swp files as well as emacs' backup
>> files ending in "~" and "#" from the search results in
>> gen_snippet_d.pl.
>>
>> Reported-by: Paul E. McKenney <paulmck@xxxxxxxxxxxxx>
>> Signed-off-by: Akira Yokosawa <akiyks@xxxxxxxxx>
>> ---
>> Paul,
>>
>> This should ignore .swp files in the dependency file.
>> Can you test "make" while opening hash_resize.c in vim?
>>
>> Thanks, Akira
>>
>> PS:
>>
>> I'll comment on the update of Quick Quiz 10.13 later this week.
>
> Works great, thank you!!!
>
> It does not handle the case where you are concurrently editing the same
> file with two different instances of "vim", but that could be considered
> a feature rather than a bug. ;-) So no need to modify further.
>
> Queued, will push with the QQ 10.13 update.
>
> And have a great week, especially if this is holiday time for you!
Thank you!
Wish we could have a calm new year!
Before commenting on QQ 10.13, I thought I needed to grasp the whole
framework under CodeSamples/datastruct/hash/ and reviewed hashtorture.h.
Just wanted to make sure, I ran the tests with a variety of sets of arguments.
[NOTE: I ran them on Ubuntu Xenial with
liburcu-dev/xenial,now 0.9.1-3 and liburcu4/xenial,now 0.9.1-3
installed. On Trusty with liburcu-dev/trusty,now 0.7.12-0ubuntu2 and
liburcu1/trusty,now 0.7.12-0ubuntu2 installed, hash_bkt_rcu fails
differently.]
Some of them sporadically end up in SIGSEGV.
Following is a list of command lines which caused SIGSEGV in 10000 iteration each:
./hash_bkt_rcu --perftest --nreaders 1 --nupdaters 2 --duration 10
./hash_bkt_rcu --perftest --nreaders 1 --nupdaters 3 --duration 10
./hash_bkt_rcu --perftest --nreaders 1 --nupdaters 4 --duration 10
./hash_bkt_rcu --perftest --nreaders 2 --nupdaters 2 --duration 10
./hash_bkt_rcu --perftest --nreaders 2 --nupdaters 3 --duration 10
./hash_bkt_rcu --perftest --nreaders 2 --nupdaters 4 --duration 10
./bash_resize --perftest --nreaders 1 --nupdaters 2 --duration 10
./bash_resize --perftest --nreaders 1 --nupdaters 2 --resizemult 2 --duration 20
./bash_resize --schroidinger --nreaders 1 --nupdaters 1 --resizemult 2 --duration 20
bash_resize looks identical to bash_bkt_rcu as long as resizing is disabled.
So it looks like "--perftest" has some racing issue when "nupderters > 1"
in these tests.
"--schroedinger" works fine as long as resizing is disabled, but does have
issues when resizing is enabled. Is "--schroedinger" supposed to work
with resizing?
I'm not that good at multi-thread debugging, and I've not looked into
the details.
It's not at all urgent, but it would be great if you could look
into them.
Thanks, Akira
>
> Thanx, Paul
> [...]
