* 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
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 o
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 AB
* 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 bug
* 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 t
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 tests
* 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 devel
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 t
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
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 th
* 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 sep
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 ann
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 fr
* 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 cons
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 separ
* 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 t
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
22 matches
Mail list logo
