Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1241779 > unrolled thread

Re: [tip:perf/core] tools lib api fs: Remove debugfs, tracefs and findfs objects

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [tip:perf/core] tools lib api fs: Remove debugfs, tracefs and  findfs objects Matt Fleming <matt@codeblueprint.co.uk> - 2015-10-07 22:20 +0200
    Re: [tip:perf/core] tools lib api fs: Remove debugfs, tracefs and  findfs objects Arnaldo Carvalho de Melo <acme@redhat.com> - 2015-10-13 21:20 +0200

#1241779 — Re: [tip:perf/core] tools lib api fs: Remove debugfs, tracefs and findfs objects

On Thu, 24 Sep, at 05:05:57PM, Michael Petlan wrote:
> 
> Hi!
> 
> Yes, we have some tests, but they really need some refactoring and then
> extending.
> 
> There are many "regression" tests that cover some extreme situations
> that failed with some kernel/perf version on some hardware. They are
> probably not very useful for the purpose mentioned here.
 
If they look anything like this,

  https://git.kernel.org/cgit/linux/kernel/git/acme/linux.git/commit/?h=perf/core&id=035827e9f2bd71a280f4eb58c65811d377ab2217

i.e. the tests trigger kernel bugs, then I think they would be useful.
If the tests are more along the lines of "you need a huge machine to
trigger the issue caught by the test", maybe not.

> Then there are some tests that should cover basic functionality and
> check for the correctness of perf's behaviour. Since it became being
> pretty messy, I have got an idea to rewrite that in a more structured
> and robust way and make it public.
 
These tests sounds incredibly useful. I would certainly feel better if
I could just hack on random pieces of tools/perf and have the safety
net of regression tests to catch mistakes.

> So I started with some skeleton and tests for perf stat builtin sub
> command [1]. My idea is to port there all the meaningful tests that
> we have at Red Hat. Then I will be happy if someone else is interested
> in contributing some more coverage, ideas or whatever...

My immediate reaction is: please put these tests into tools/perf, do
not create a separate repository.

Now, you've probably got a good reason for wanting to do that, but
definitely let's discuss it first before you go ahead and invest time
and energy in porting things.

You can see my current line of thinking for perf testing with the
perf arch tests series,

  https://lkml.kernel.org/r/1444056021-25721-1-git-send-email-matt@codeblueprint.co.uk  

I think tools/perf as a concenpt (include the userland tool in the
same repo as the kernel) has been very successful because you
frequently get the same developer writing both the userspace and
kernel code. Extending that so the same developer writes the
regression tests too (at the time they introduce their new code!) is
crucial.

-- 
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1246062

Em Wed, Oct 07, 2015 at 09:10:30PM +0100, Matt Fleming escreveu:
> On Thu, 24 Sep, at 05:05:57PM, Michael Petlan wrote:
> > 
> > Hi!
> > 
> > Yes, we have some tests, but they really need some refactoring and then
> > extending.
> > 
> > There are many "regression" tests that cover some extreme situations
> > that failed with some kernel/perf version on some hardware. They are
> > probably not very useful for the purpose mentioned here.
>  
> If they look anything like this,
> 
>   https://git.kernel.org/cgit/linux/kernel/git/acme/linux.git/commit/?h=perf/core&id=035827e9f2bd71a280f4eb58c65811d377ab2217
> 
> i.e. the tests trigger kernel bugs, then I think they would be useful.
> If the tests are more along the lines of "you need a huge machine to
> trigger the issue caught by the test", maybe not.
> 
> > Then there are some tests that should cover basic functionality and
> > check for the correctness of perf's behaviour. Since it became being
> > pretty messy, I have got an idea to rewrite that in a more structured
> > and robust way and make it public.
>  
> These tests sounds incredibly useful. I would certainly feel better if
> I could just hack on random pieces of tools/perf and have the safety
> net of regression tests to catch mistakes.
> 
> > So I started with some skeleton and tests for perf stat builtin sub
> > command [1]. My idea is to port there all the meaningful tests that
> > we have at Red Hat. Then I will be happy if someone else is interested
> > in contributing some more coverage, ideas or whatever...
> 
> My immediate reaction is: please put these tests into tools/perf, do
> not create a separate repository.

Right, agreed, we need to look at what we have, how a new build test is
done, for instance, how those perf_event_attr tests using a python
harness, etc, but more than anything, we need as many regression tests
as possible, so yeah, please try to have it somehow hooked into 'perf
test' and aim to have whatever tests you have ran when whoever runs
'perf test'.

- Arnaldo
 
> Now, you've probably got a good reason for wanting to do that, but
> definitely let's discuss it first before you go ahead and invest time
> and energy in porting things.
> 
> You can see my current line of thinking for perf testing with the
> perf arch tests series,
> 
>   https://lkml.kernel.org/r/1444056021-25721-1-git-send-email-matt@codeblueprint.co.uk  
> 
> I think tools/perf as a concenpt (include the userland tool in the
> same repo as the kernel) has been very successful because you
> frequently get the same developer writing both the userspace and
> kernel code. Extending that so the same developer writes the
> regression tests too (at the time they introduce their new code!) is
> crucial.
> 
> -- 
> Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web