| Message ID | 20220210083356.11212-1-krzysztof.kozlowski@canonical.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 6fec1ab67f8d60704cc7de64abcfd389ab131542 |
| Headers | show |
| Series | [v2] selftests/ftrace: Do not trace do_softirq because of PREEMPT_RT | expand |
On 2022-02-10 09:33:56 [+0100], Krzysztof Kozlowski wrote: > The PREEMPT_RT patchset does not use soft IRQs thus trying to filter for > do_softirq fails for such kernel: PREEMPT_RT does use soft IRQs. > echo do_softirq > ftracetest: 81: echo: echo: I/O error > > Choose some other visible function for the test. > … > --- a/tools/testing/selftests/ftrace/test.d/ftrace/func_set_ftrace_file.tc > +++ b/tools/testing/selftests/ftrace/test.d/ftrace/func_set_ftrace_file.tc > @@ -19,7 +19,7 @@ fail() { # mesg > > FILTER=set_ftrace_filter > FUNC1="schedule" > -FUNC2="do_softirq" > +FUNC2="scheduler_tick" What is the purpose of this? > ALL_FUNCS="#### all functions enabled ####" > Sebastian
On 10/02/2022 14:47, Sebastian Andrzej Siewior wrote: > On 2022-02-10 09:33:56 [+0100], Krzysztof Kozlowski wrote: >> The PREEMPT_RT patchset does not use soft IRQs thus trying to filter for >> do_softirq fails for such kernel: > > PREEMPT_RT does use soft IRQs. Correct. It does not use do_softirq() code, but follows different path with ksoftirqd. Shall I rephrase it towards something like this? Or maybe you have some more accurate description? The implementation detail is that do_softirq() is in ifndef. > >> echo do_softirq >> ftracetest: 81: echo: echo: I/O error >> >> Choose some other visible function for the test. >> > … > >> --- a/tools/testing/selftests/ftrace/test.d/ftrace/func_set_ftrace_file.tc >> +++ b/tools/testing/selftests/ftrace/test.d/ftrace/func_set_ftrace_file.tc >> @@ -19,7 +19,7 @@ fail() { # mesg >> >> FILTER=set_ftrace_filter >> FUNC1="schedule" >> -FUNC2="do_softirq" >> +FUNC2="scheduler_tick" > > What is the purpose of this? > >> ALL_FUNCS="#### all functions enabled ####" >> > > Sebastian Best regards, Krzysztof
On 2022-02-10 15:05:24 [+0100], Krzysztof Kozlowski wrote: > On 10/02/2022 14:47, Sebastian Andrzej Siewior wrote: > > On 2022-02-10 09:33:56 [+0100], Krzysztof Kozlowski wrote: > >> The PREEMPT_RT patchset does not use soft IRQs thus trying to filter for > >> do_softirq fails for such kernel: > > > > PREEMPT_RT does use soft IRQs. > > Correct. It does not use do_softirq() code, but follows different path > with ksoftirqd. > Shall I rephrase it towards something like this? Or maybe you have some > more accurate description? It would be good to describe what the purpose of the change in terms of the actual problem and the aimed solution. > The implementation detail is that do_softirq() is in ifndef. So let me ask again. We have FUNC1="schedule" FUNC2="do_softirq" What is the purpose of this? Do you need FUNC2 when ksoftirqd is run or when softirqs are served? Not sure how scheduler_tick fits in all this. > Best regards, > Krzysztof Sebastian
On 10/02/2022 15:10, Sebastian Andrzej Siewior wrote: > On 2022-02-10 15:05:24 [+0100], Krzysztof Kozlowski wrote: >> On 10/02/2022 14:47, Sebastian Andrzej Siewior wrote: >>> On 2022-02-10 09:33:56 [+0100], Krzysztof Kozlowski wrote: >>>> The PREEMPT_RT patchset does not use soft IRQs thus trying to filter for >>>> do_softirq fails for such kernel: >>> >>> PREEMPT_RT does use soft IRQs. >> >> Correct. It does not use do_softirq() code, but follows different path >> with ksoftirqd. >> Shall I rephrase it towards something like this? Or maybe you have some >> more accurate description? > > It would be good to describe what the purpose of the change in terms of > the actual problem and the aimed solution. The purpose was explain - fix a failing test with PREEMPT_RT. I am not planning to rework entire test, it is merely a fix. > >> The implementation detail is that do_softirq() is in ifndef. > > So let me ask again. We have > FUNC1="schedule" > FUNC2="do_softirq" > > What is the purpose of this? Do you need FUNC2 when ksoftirqd is run or > when softirqs are served? Not sure how scheduler_tick fits in all this. I guess this is more a question to the author of the test. Unless you are now questioning the entire purpose of this test? Best regards, Krzysztof
On 2022-02-10 15:13:15 [+0100], Krzysztof Kozlowski wrote: > On 10/02/2022 15:10, Sebastian Andrzej Siewior wrote: > > The purpose was explain - fix a failing test with PREEMPT_RT. I am not > planning to rework entire test, it is merely a fix. What I got confused by is the fact that you do s/do_softirq/scheduler_tick/ without any explanation why that is correct. After looking into the test it appears that two random functions are enough to be specified because the actual purpose is it to figure out if the function is recorded and not the actual functionality behind the function. > >> The implementation detail is that do_softirq() is in ifndef. > > > > So let me ask again. We have > > FUNC1="schedule" > > FUNC2="do_softirq" > > > > What is the purpose of this? Do you need FUNC2 when ksoftirqd is run or > > when softirqs are served? Not sure how scheduler_tick fits in all this. > > I guess this is more a question to the author of the test. Unless you > are now questioning the entire purpose of this test? I questioned the purpose of FUNC2 in this context so I don't have to look into the actual test. But I did, see above ;) > Best regards, > Krzysztof Sebastian
On Thu, 10 Feb 2022 15:13:15 +0100 Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> wrote: > >> The implementation detail is that do_softirq() is in ifndef. > > > > So let me ask again. We have > > FUNC1="schedule" > > FUNC2="do_softirq" > > > > What is the purpose of this? Do you need FUNC2 when ksoftirqd is run or > > when softirqs are served? Not sure how scheduler_tick fits in all this. > > I guess this is more a question to the author of the test. Unless you > are now questioning the entire purpose of this test? The test is just a smoke test on function triggers. These two functions have various triggers attached to them to see if it causes any harm (the test was added after some strange bugs happened in the past). Now, if "_printk" worked, it suggests that I need to look into this test because I'm guessing _printk would never trigger during the test. The reason we picked schedule and do_softirq was to get triggers in different contexts (do_softirq was in the softirq context, and schedule is in the normal context). The reason I suggested to pick "schedule_tick" is because that should happen in the interrupt context. But if _printk worked, then it probably didn't test that part. But that's a different bug than what this patch is addressing. Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org> And I need to add to my TODO list, to look at this test and probably rewrite. it. :-p -- Steve
On Thu, 10 Feb 2022 15:48:41 +0100 Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote: > After looking into the test it appears that two random functions are > enough to be specified because the actual purpose is it to figure out if > the function is recorded and not the actual functionality behind the > function. Correct. And if I ever do get a chance to revisit this test, I plan on adding a bunch of comments to it. It's hard enough to add tests for one's code, but even harder to document what those tests actually do ;-) -- Steve
diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func_set_ftrace_file.tc b/tools/testing/selftests/ftrace/test.d/ftrace/func_set_ftrace_file.tc index e96e279e0533..25432b8cd5bd 100644 --- a/tools/testing/selftests/ftrace/test.d/ftrace/func_set_ftrace_file.tc +++ b/tools/testing/selftests/ftrace/test.d/ftrace/func_set_ftrace_file.tc @@ -19,7 +19,7 @@ fail() { # mesg FILTER=set_ftrace_filter FUNC1="schedule" -FUNC2="do_softirq" +FUNC2="scheduler_tick" ALL_FUNCS="#### all functions enabled ####"