* Arnaldo Carvalho de Melo wrote:
> Em Tue, Aug 13, 2013 at 05:57:16PM -0400, Vince Weaver escreveu:
> > On Tue, 13 Aug 2013, Ingo Molnar wrote:
> >
> > > that can only be addressed by either extending 'perf test' or by
> > > testing libpfm et al sooner. The upstream kernel can only address
>
Em Tue, Aug 13, 2013 at 05:57:16PM -0400, Vince Weaver escreveu:
> On Tue, 13 Aug 2013, Ingo Molnar wrote:
> > that can only be addressed by either extending 'perf test' or by testing
> > libpfm et al sooner. The upstream kernel can only address regressions that
> > get reported.
> Most of the
Em Tue, Aug 13, 2013 at 05:57:16PM -0400, Vince Weaver escreveu:
On Tue, 13 Aug 2013, Ingo Molnar wrote:
that can only be addressed by either extending 'perf test' or by testing
libpfm et al sooner. The upstream kernel can only address regressions that
get reported.
Most of the tests
* Arnaldo Carvalho de Melo a...@ghostprotocols.net wrote:
Em Tue, Aug 13, 2013 at 05:57:16PM -0400, Vince Weaver escreveu:
On Tue, 13 Aug 2013, Ingo Molnar wrote:
that can only be addressed by either extending 'perf test' or by
testing libpfm et al sooner. The upstream kernel can
On Tue, Aug 13, 2013 at 05:57:16PM -0400, Vince Weaver wrote:
> On Tue, 13 Aug 2013, Ingo Molnar wrote:
>
> >
> > that can only be addressed by either extending 'perf test' or by testing
> > libpfm et al sooner. The upstream kernel can only address regressions that
> > get reported.
>
> Most
On Tue, 13 Aug 2013, Ingo Molnar wrote:
>
> that can only be addressed by either extending 'perf test' or by testing
> libpfm et al sooner. The upstream kernel can only address regressions that
> get reported.
Most of the tests in my test-suite are reactive. Meaning, I wrote them
after an
* Vince Weaver wrote:
> On Tue, 13 Aug 2013, Ingo Molnar wrote:
> > * Vince Weaver wrote:
>
> > In the past you used to only test your library once the -stable kernel was
> > released - has this changed recently by any chance? I remember that in one
> > particular case I got a regression
* Arnaldo Carvalho de Melo wrote:
> Em Tue, Aug 13, 2013 at 12:48:21PM +0200, Ingo Molnar escreveu:
> > To resolve this situation you could help us out by doing either of these:
>
> > 1) integrate your tests into tools/, there's 'perf test' that has a ton
> > of testcases already
>
> I
On Tue, 13 Aug 2013, Ingo Molnar wrote:
> * Vince Weaver wrote:
> In the past you used to only test your library once the -stable kernel was
> released - has this changed recently by any chance? I remember that in one
> particular case I got a regression bugreport from you essentially on the
Em Tue, Aug 13, 2013 at 12:48:21PM +0200, Ingo Molnar escreveu:
> To resolve this situation you could help us out by doing either of these:
> 1) integrate your tests into tools/, there's 'perf test' that has a ton
> of testcases already
I think Jiri is working on merging some of those
* Vince Weaver wrote:
> On Mon, 12 Aug 2013, Ingo Molnar wrote:
>
> > perf is the exact opposite: no split-up the development culture
> > because they are closely related, yet a relatively disciplined ABI
> > between the components. In fact the ABI is higher quality exactly
> > because
* Vince Weaver vi...@deater.net wrote:
On Mon, 12 Aug 2013, Ingo Molnar wrote:
perf is the exact opposite: no split-up the development culture
because they are closely related, yet a relatively disciplined ABI
between the components. In fact the ABI is higher quality exactly
Em Tue, Aug 13, 2013 at 12:48:21PM +0200, Ingo Molnar escreveu:
To resolve this situation you could help us out by doing either of these:
1) integrate your tests into tools/, there's 'perf test' that has a ton
of testcases already
I think Jiri is working on merging some of those tests,
On Tue, 13 Aug 2013, Ingo Molnar wrote:
* Vince Weaver vi...@deater.net wrote:
In the past you used to only test your library once the -stable kernel was
released - has this changed recently by any chance? I remember that in one
particular case I got a regression bugreport from you
* Arnaldo Carvalho de Melo a...@ghostprotocols.net wrote:
Em Tue, Aug 13, 2013 at 12:48:21PM +0200, Ingo Molnar escreveu:
To resolve this situation you could help us out by doing either of these:
1) integrate your tests into tools/, there's 'perf test' that has a ton
of testcases
* Vince Weaver vi...@deater.net wrote:
On Tue, 13 Aug 2013, Ingo Molnar wrote:
* Vince Weaver vi...@deater.net wrote:
In the past you used to only test your library once the -stable kernel was
released - has this changed recently by any chance? I remember that in one
particular case
On Tue, 13 Aug 2013, Ingo Molnar wrote:
that can only be addressed by either extending 'perf test' or by testing
libpfm et al sooner. The upstream kernel can only address regressions that
get reported.
Most of the tests in my test-suite are reactive. Meaning, I wrote them
after an
On Tue, Aug 13, 2013 at 05:57:16PM -0400, Vince Weaver wrote:
On Tue, 13 Aug 2013, Ingo Molnar wrote:
that can only be addressed by either extending 'perf test' or by testing
libpfm et al sooner. The upstream kernel can only address regressions that
get reported.
Most of the tests
On Mon, 12 Aug 2013, Ingo Molnar wrote:
> perf is the exact opposite: no split-up the development culture because
> they are closely related, yet a relatively disciplined ABI between the
> components. In fact the ABI is higher quality exactly because development
> is more integrated and allows
* Christoph Hellwig wrote:
> On Mon, Aug 05, 2013 at 11:08:57AM +0200, Ingo Molnar wrote:
> > You never replied to the original counter-arguments, such as this one from
> > Linus:
> >
> > http://article.gmane.org/gmane.linux.kernel/849965
>
> The only thing Linus sais is that it's trivial
* Christoph Hellwig h...@infradead.org wrote:
On Mon, Aug 05, 2013 at 11:08:57AM +0200, Ingo Molnar wrote:
You never replied to the original counter-arguments, such as this one from
Linus:
http://article.gmane.org/gmane.linux.kernel/849965
The only thing Linus sais is that it's
On Mon, 12 Aug 2013, Ingo Molnar wrote:
perf is the exact opposite: no split-up the development culture because
they are closely related, yet a relatively disciplined ABI between the
components. In fact the ABI is higher quality exactly because development
is more integrated and allows for
On Mon, Aug 05, 2013 at 11:08:57AM +0200, Ingo Molnar wrote:
> You never replied to the original counter-arguments, such as this one from
> Linus:
>
> http://article.gmane.org/gmane.linux.kernel/849965
The only thing Linus sais is that it's trivial to generate a subpackage,
and that opofile
On Mon, Aug 05, 2013 at 11:08:57AM +0200, Ingo Molnar wrote:
You never replied to the original counter-arguments, such as this one from
Linus:
http://article.gmane.org/gmane.linux.kernel/849965
The only thing Linus sais is that it's trivial to generate a subpackage,
and that opofile is a
Namhyung Kim writes:
>
> I wrote a patch series [1] separating gtk code to a dso and use it with
> libdl last year. But I didn't get much feedback probably due to the
> mistake of not installing the dso to a proper place. It'd be great if
> you guys take a look at it and give some comments.
It
On Mon, Aug 5, 2013 at 12:12 PM, Ingo Molnar wrote:
> Assuming that in the normal case it can be made to work like a full build
> of perf today (i.e. without forcing LD_PRELOAD) then splitting the
> libraries away looks like a much better solution than splitting the
> binary.
Yup, if we can make
* Namhyung Kim wrote:
> Hi,
>
> On Mon, 5 Aug 2013 01:23:20 -0700, Christoph Hellwig wrote:
> > On Mon, Aug 05, 2013 at 10:16:41AM +0200, Ingo Molnar wrote:
> >> If you want fewer dependencies then build with 'make NO_GTK=1'.
> >
> > Doesn't help the distros. Installing perf and pulling all
* Christoph Hellwig wrote:
> On Mon, Aug 05, 2013 at 10:31:32AM +0200, Ingo Molnar wrote:
>
> > Nonsense, a distro, if it truly worried about this, could create two
> > packages already, there's no need to expose configuration options in
> > the binary name itself and burden users with the
Hi,
On Mon, 5 Aug 2013 01:23:20 -0700, Christoph Hellwig wrote:
> On Mon, Aug 05, 2013 at 10:16:41AM +0200, Ingo Molnar wrote:
>> If you want fewer dependencies then build with 'make NO_GTK=1'.
>
> Doesn't help the distros. Installing perf and pulling all the graphics
> libraries in is highly
On Mon, Aug 05, 2013 at 10:31:32AM +0200, Ingo Molnar wrote:
> Nonsense, a distro, if it truly worried about this, could create two
> packages already, there's no need to expose configuration options in the
> binary name itself and burden users with the separation. I sometimes
> switch the UI
* Christoph Hellwig wrote:
> On Mon, Aug 05, 2013 at 10:16:41AM +0200, Ingo Molnar wrote:
>
> > If you want fewer dependencies then build with 'make NO_GTK=1'.
>
> Doesn't help the distros. Installing perf and pulling all the graphics
> libraries in is highly annoying, especially in size
On Mon, Aug 05, 2013 at 10:16:41AM +0200, Ingo Molnar wrote:
> If you want fewer dependencies then build with 'make NO_GTK=1'.
Doesn't help the distros. Installing perf and pulling all the graphics
libraries in is highly annoying, especially in size constrained VM or
Cloud images. Having a
* Andi Kleen wrote:
> From: Andi Kleen
>
> By default perf currently links with the GTK2 gui. This pulls
> in a lot of external libraries. It also causes dependency
> problems for distribution packages: simply installing perf
> requires pulling in GTK2 with all its dependencies.
>
> I think
* Andi Kleen a...@firstfloor.org wrote:
From: Andi Kleen a...@linux.intel.com
By default perf currently links with the GTK2 gui. This pulls
in a lot of external libraries. It also causes dependency
problems for distribution packages: simply installing perf
requires pulling in GTK2 with
On Mon, Aug 05, 2013 at 10:16:41AM +0200, Ingo Molnar wrote:
If you want fewer dependencies then build with 'make NO_GTK=1'.
Doesn't help the distros. Installing perf and pulling all the graphics
libraries in is highly annoying, especially in size constrained VM or
Cloud images. Having a
* Christoph Hellwig h...@infradead.org wrote:
On Mon, Aug 05, 2013 at 10:16:41AM +0200, Ingo Molnar wrote:
If you want fewer dependencies then build with 'make NO_GTK=1'.
Doesn't help the distros. Installing perf and pulling all the graphics
libraries in is highly annoying, especially
On Mon, Aug 05, 2013 at 10:31:32AM +0200, Ingo Molnar wrote:
Nonsense, a distro, if it truly worried about this, could create two
packages already, there's no need to expose configuration options in the
binary name itself and burden users with the separation. I sometimes
switch the UI
Hi,
On Mon, 5 Aug 2013 01:23:20 -0700, Christoph Hellwig wrote:
On Mon, Aug 05, 2013 at 10:16:41AM +0200, Ingo Molnar wrote:
If you want fewer dependencies then build with 'make NO_GTK=1'.
Doesn't help the distros. Installing perf and pulling all the graphics
libraries in is highly
* Christoph Hellwig h...@infradead.org wrote:
On Mon, Aug 05, 2013 at 10:31:32AM +0200, Ingo Molnar wrote:
Nonsense, a distro, if it truly worried about this, could create two
packages already, there's no need to expose configuration options in
the binary name itself and burden users
* Namhyung Kim namhy...@kernel.org wrote:
Hi,
On Mon, 5 Aug 2013 01:23:20 -0700, Christoph Hellwig wrote:
On Mon, Aug 05, 2013 at 10:16:41AM +0200, Ingo Molnar wrote:
If you want fewer dependencies then build with 'make NO_GTK=1'.
Doesn't help the distros. Installing perf and
On Mon, Aug 5, 2013 at 12:12 PM, Ingo Molnar mi...@kernel.org wrote:
Assuming that in the normal case it can be made to work like a full build
of perf today (i.e. without forcing LD_PRELOAD) then splitting the
libraries away looks like a much better solution than splitting the
binary.
Yup, if
Namhyung Kim namhy...@kernel.org writes:
I wrote a patch series [1] separating gtk code to a dso and use it with
libdl last year. But I didn't get much feedback probably due to the
mistake of not installing the dso to a proper place. It'd be great if
you guys take a look at it and give some
From: Andi Kleen
By default perf currently links with the GTK2 gui. This pulls
in a lot of external libraries. It also causes dependency
problems for distribution packages: simply installing perf
requires pulling in GTK2 with all its dependencies.
I think the UI is valuable, but it shouldn't be
From: Andi Kleen a...@linux.intel.com
By default perf currently links with the GTK2 gui. This pulls
in a lot of external libraries. It also causes dependency
problems for distribution packages: simply installing perf
requires pulling in GTK2 with all its dependencies.
I think the UI is valuable,
44 matches
Mail list logo
