From: Akira Yokosawa <akiyks@gmail.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: luc.maranget@inria.fr, Andrii Nakryiko <andriin@fb.com>,
"Paul E . McKenney" <paulmck@kernel.org>,
Alan Stern <stern@rowland.harvard.edu>,
Peter Zijlstra <peterz@infradead.org>,
parri.andrea@gmail.com, will@kernel.org, boqun.feng@gmail.com,
npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk,
dlustig@nvidia.com, Joel Fernandes <joel@joelfernandes.org>,
open list <linux-kernel@vger.kernel.org>,
linux-arch@vger.kernel.org
Subject: Re: Some -serious- BPF-related litmus tests
Date: Tue, 26 May 2020 23:02:48 +0900 [thread overview]
Message-ID: <b92f9c0a-826c-d074-5389-8c340f7cccf2@gmail.com> (raw)
In-Reply-To: <d1113b47-a920-c0e4-9aa4-88781368a26f@gmail.com>
On Tue, 26 May 2020 19:50:47 +0900, Akira Yokosawa wrote:
> On Mon, 25 May 2020 16:31:05 -0700, Andrii Nakryiko wrote:
>> On Mon, May 25, 2020 at 3:01 PM Akira Yokosawa <akiyks@gmail.com> wrote:
>>>
> [...]
>>> Yes, that should work.
>>
>> Ok, assigning to zero didn't work (it still complained about
>> uninitialized read), but using a separate int *lenFail to assign to
>> rLenPtr worked. Curiously, if I used rLenPtr = len1; in error case, it
>> actually takes a bit more time to verify.
>>
>> So I've converted everything else as you suggested. I compiled latest
>> herd7 and it doesn't produce any warnings. But it's also extremely
>> slow, compared to the herd7 that I get by default. Validating simple
>> 1p1c cases takes about 2.5x times longer (0.03s vs 0.07),
Wait a moment!
This 0.03s was the run time of the original 1p1c litmus test, wasn't it?
Then you are comparing apples and oranges.
How long does your default herd7 take to complete the updated 1p1c test?
Thanks, Akira
>> but trying
>> to validate 2p1c case, which normally validates in 42s (unbounded) and
>> 110s (bounded), it took more than 20 minutes and hasn't finished,
>> before I gave up. So I don't know what's going on there...
>
> herdtools7 has recently been heavily restructured.
> On the performance regression, I must defer to Luc.
>
> Luc, do you have any idea?
>
>>
>> As for klitmus7, I managed to generate everything without warnings,
>> but couldn't make it build completely due to:
>>
>> $ make
>> make -C /lib/modules/5.6.13-01802-g938d64da97c6/build/
>
> So you are on Linux 5.6.x which requires cutting-edge klitmus7.
>
>> M=/home/andriin/local/linux-trees/tools/memory-model/mymodules modules
>> make[1]: Entering directory `/data/users/andriin/linux-build/fb-config'
>> make[2]: Entering directory `/data/users/andriin/linux-build/default-x86_64'
>> CC [M] /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.o
>> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:
>> In function ‘zyva’:
>> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:507:12:
>> warning: ISO C90 forbids variable length array ‘th’ [-Wvla]
>> struct task_struct *th[nth];
>> ^~~~~~~~~~~
>> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:
>> In function ‘litmus_init’:
>> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:605:67:
>> error: passing argument 4 of ‘proc_create’ from incompatible pointer
>> type [-Werror=incompatible-pointer-types]
>> struct proc_dir_entry *litmus_pde =
>> proc_create("litmus",0,NULL,&litmus_proc_fops);
>>
>> ^~~~~~~~~~~~~~~~~
>> In file included from
>> /home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.c:15:
>> /data/users/andriin/linux-fb/include/linux/proc_fs.h:64:24: note:
>> expected ‘const struct proc_ops *’ but argument is of type ‘const
>> struct file_operations *’
>> struct proc_dir_entry *proc_create(const char *name, umode_t mode,
>> struct proc_dir_entry *parent, const struct proc_ops *proc_ops);
>> ^~~~~~~~~~~
>> cc1: some warnings being treated as errors
>> make[3]: *** [/home/andriin/local/linux-trees/tools/memory-model/mymodules/litmus000.o]
>> Error 1
>> make[2]: *** [/home/andriin/local/linux-trees/tools/memory-model/mymodules]
>> Error 2
>> make[2]: Leaving directory `/data/users/andriin/linux-build/default-x86_64'
>> make[1]: *** [sub-make] Error 2
>> make[1]: Leaving directory `/data/users/andriin/linux-build/fb-config'
>> make: *** [all] Error 2
>>
>
> These errors suggest the klitmus7 you used is version 7.52 or some such.
> You said you have built herd7 from the source. Have you also built klitmus7?
>
> The up-to-date klitmus7 should generate code compatible with Linux 5.6.x.
>
> Could you try with the latest one?
>
> Thanks, Akira
>
>>
>> But at least it doesn't complain about atomic_t anymore. So anyways,
>> I'm going to post updated litmus tests separately from BPF ringbuf
>> patches, because Documentation/litmus-tests is not yet present in
>> bpf-next.
>>
>>>
>>> You can find a basic introduction of klitmus7 in tools/memory-model/README.
>>>
>>> Thanks, Akira
>>>
>>>>
>>>>>
>>>>> Please note that if you are on Linux 5.6 (or later), you need an up-to-date
>>>>> klitmus7 due to a change in kernel API.
>>>>>
>>>>> Any question is welcome!
>>>>>
>>>>> Thanks, Akira
>>>>>
>>
>> [...]
>>
>
next prev parent reply other threads:[~2020-05-26 14:02 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-22 0:38 Paul E. McKenney
2020-05-22 9:44 ` Peter Zijlstra
2020-05-22 10:56 ` Paul E. McKenney
2020-05-22 14:36 ` Alan Stern
2020-05-22 17:45 ` Paul E. McKenney
2020-05-22 14:32 ` Alan Stern
2020-05-22 17:43 ` Paul E. McKenney
2020-05-22 19:38 ` Andrii Nakryiko
2020-05-24 12:09 ` Akira Yokosawa
2020-05-25 18:31 ` Andrii Nakryiko
2020-05-25 22:01 ` Akira Yokosawa
2020-05-25 23:31 ` Andrii Nakryiko
2020-05-26 10:50 ` Akira Yokosawa
2020-05-26 14:02 ` Akira Yokosawa [this message]
2020-05-26 20:19 ` Andrii Nakryiko
2020-05-26 23:00 ` Akira Yokosawa
2020-05-27 0:09 ` Andrii Nakryiko
2020-05-26 20:15 ` Andrii Nakryiko
2020-05-26 22:23 ` Akira Yokosawa
2020-05-25 11:25 ` Peter Zijlstra
2020-05-25 15:47 ` Paul E. McKenney
2020-05-25 17:02 ` Peter Zijlstra
2020-05-25 17:21 ` Paul E. McKenney
2020-05-25 17:45 ` Paul E. McKenney
2020-05-28 22:00 ` Joel Fernandes
2020-05-28 22:16 ` Peter Zijlstra
2020-05-29 5:14 ` Andrii Nakryiko
2020-05-29 12:36 ` Peter Zijlstra
2020-05-29 20:01 ` Andrii Nakryiko
2020-05-29 20:53 ` Peter Zijlstra
2020-05-25 14:53 ` Boqun Feng
2020-05-25 18:38 ` Andrii Nakryiko
2020-05-28 21:48 ` Joel Fernandes
2020-05-29 4:38 ` Andrii Nakryiko
2020-05-29 17:23 ` Joel Fernandes
2020-05-29 20:10 ` Andrii Nakryiko
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=b92f9c0a-826c-d074-5389-8c340f7cccf2@gmail.com \
--to=akiyks@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andriin@fb.com \
--cc=boqun.feng@gmail.com \
--cc=dhowells@redhat.com \
--cc=dlustig@nvidia.com \
--cc=j.alglave@ucl.ac.uk \
--cc=joel@joelfernandes.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.maranget@inria.fr \
--cc=npiggin@gmail.com \
--cc=parri.andrea@gmail.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=stern@rowland.harvard.edu \
--cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome