From: Avi Kivity on
On 03/22/2010 04:32 PM, Ingo Molnar wrote:
> * Avi Kivity<avi(a)redhat.com> wrote:
>
>
>> On 03/22/2010 02:44 PM, Ingo Molnar wrote:
>>
>>> This is why i consider that line of argument rather dishonest ...
>>>
>> I am not going to reply to any more email from you on this thread.
>>
> Because i pointed out that i consider a line of argument intellectually
> dishonest?
>
> I did not say _you_ as a person are dishonest - doing that would be an ad
> honimen attack against your person. (In fact i dont think you are, to the
> contrary)
>
> An argument can certainly be labeled dishonest in a fair discussion and it is
> not a personal attack against you to express my opinion about that.
>
>

Sigh, why am I drawn into this.

A person who uses dishonest arguments is a dishonest person. When you
say I use a dishonest argument you are implying I am dishonest. Why do
you argue with me at all if you think I am trying to cheat?

If you disagree with me, tell me I am wrong, not dishonest (or that my
arguments are dishonest). And this is just one example in this thread.
Seriously, tools/kvm would cause a loss of developers, not a gain,
simply because of the style of argument of some people on this list.
Maybe qemu/kernels is a better idea.

Again, if you want to talk to me, use the same language you'd like to
hear yourself. Or maybe years of lkml made you so thick skinned you no
longer understand how to interact with people.

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on

* Avi Kivity <avi(a)redhat.com> wrote:

> On 03/22/2010 01:23 PM, Ingo Molnar wrote:
> >* Avi Kivity<avi(a)redhat.com> wrote:
> >
> >>IMO the reason perf is more usable than oprofile has less to do with the
> >>kernel/userspace boundary and more do to with effort and attention spent on
> >>the userspace/user boundary.
> >>
> >>[...]
> >
> > If you are interested in the first-hand experience of the people who are
> > doing the perf work then here it is: by far the biggest reason for perf
> > success and perf usability is the integration of the user-space tooling
> > with the kernel-space bits, into a single repository and project.
>
> Please take a look at the kvm integration code in qemu as a fraction of the
> whole code base.

You have to admit that much of Qemu's past 2-3 years of development was
motivated by Linux/KVM (i'd say more than 50% of the code). As such it's one
and the same code base - you just continue to define Qemu to be different from
KVM.

I very much remember how Qemu looked like _before_ KVM: it was a struggling,
dying project. KVM clearly changed that.

> > The very move you are opposing so vehemently for KVM.
>
> I don't want to fracture a working community.

Would you accept (or at least not NAK) a new tools/kvm/ tool that builds
tooling from grounds up, while leaving Qemu untouched? [assuming it's all
clean code, etc.]

Although i have doubts about how well that would work 'against' your opinion:
such a tool would need lots of KVM-side features and a positive attitude from
you to be really useful. There's a lot of missing functionality to cover.

> > Oprofile went the way you proposed, and it was a failure. It failed not
> > because it was bad technology (it was pretty decent and people used it),
> > it was not a failure because the wrong people worked on it (to the
> > contrary, very capable people worked on it), it was a failure in hindsight
> > because it simply incorrectly split into two projects which stiffled the
> > progress of each other.
>
> Every project that has some kernel footprint, except perf, is split like
> that. Are they all failures?

No. Did i ever claim KVM was a failure? I said it's hindered by this design
aspect.

Are other Linux kernel tool projects affected by similar problems? You bet ...

> Seems like perf is also split, with sysprof being developed outside the
> kernel. Will you bring sysprof into the kernel? Will every feature be
> duplicated in prof and sysprof?

I'd prefer if sysprof merged into perf as 'perf view' - but its maintainer
does not want that - which is perfectly OK. So we are building equivalent
functionality into perf instead.

Think about it like Firefox plugins: the main Firefox project picks up the
functionality of the most popular Firefox plugins all the time. Session Saver,
Tab Mix Plus, etc. were all in essence 'merged' (in functionality, not in
code) into the 'reference' Firefox project.

I think that's a fundamentally healthy model: it allows extensions and thus
give others an honest chance to show that you are potentially coding an
inferior piece of code - but also express a clear opinion about what you
consider a full, usable, high-quality reference implementation and constantly
improve this reference implementation.

I dont think that can be argued to be a bad model. Yes, it takes a bit of
thinking outside the box to do tools/kvm/ but of all people i'd expect some of
that from you.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on

* Pekka Enberg <penberg(a)cs.helsinki.fi> wrote:

> Hi Avi,
>
> On Mon, Mar 22, 2010 at 2:49 PM, Avi Kivity <avi(a)redhat.com> wrote:
> > Seems like perf is also split, with sysprof being developed outside the
> > kernel. ?Will you bring sysprof into the kernel? ?Will every feature be
> > duplicated in prof and sysprof?
>
> I am glad you brought it up! Sysprof was historically outside of the kernel
> (with it's own kernel module, actually). While the GUI was nice, it was much
> harder to set up compared to oprofile so it wasn't all that popular. Things
> improved slightly when Ingo merged the custom kernel module but the
> _userspace_ part of sysprof was lagging behind a bit. I don't know what's
> the situation now that they've switched over to perf syscalls but you
> probably get my point.
>
> It would be nice if the two projects merged but I honestly don't see any
> fundamental problem with two (or more) co-existing projects. Friendly
> competition will ultimately benefit the users (think KDE and Gnome here).

See my previous mail - what i see as the most healthy project model is to have
a full solution reference implementation, connected to a flexible halo of
plugins or sub-apps.

Firefox does that, KDE does that, and Gnome as well to a certain degree.

The 'halo' provides a constant feedback of new features, and it also provides
competition and pressure on the 'main' code to be top-notch.

The problem i see with KVM is that there's no reference implementation! There
is _only_ the KVM kernel part which is not functional in itself. Surrounded by
a 'halo' - where none of the entities is really 'the' reference implementation
we call 'KVM'.

This causes constant quality problems as the developers of the main project
dont have constant pressure towards good quality (it is not their
responsibility to care about user-space bits after all), plus it causes a lack
of focus as well: integration between (friendly) competing user-space
components is a lot harder than integration within a single framework such as
Firefox.

I hope this explains my points about modularization a bit better! I suggested
KVM to grow a user-space tool component in the kernel repo in tools/kvm/,
which would become the reference implementation for tooling. User-space
projects can still provide alternative tooling or can plug into this tooling,
just like they are doing it now. So the main effect isnt even on those
projects but on the kernel developers. The ABI remains and all the user-space
packages and projects remain.

Yes, i thought Qemu would be a prime candidate to be the baseline for
tools/kvm/, but i guess that has become socially impossible now after this
flamewar. It's not a big problem in the big scheme of things: tools/kvm/ is
best grown up from a small towards larger size anyway ...

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on

* Anthony Liguori <anthony(a)codemonkey.ws> wrote:

> [...]
>
> I've been trying very hard to turn this into a productive thread attempting
> to capture your feedback and give clear suggestions about how you can solve
> achieve your desired functionality.

I'm glad that we are at this more productive stage. I'm still trying to
achieve the very same technological capabilities that i expressed in the first
few mails when i reviewed the 'perf kvm' patch that was submitted by Yanmin.

The crux of the problem is very simple. To quote my earlier mail:

|
| - The inconvenience of having to type:
| perf kvm --host --guest --guestkallsyms=/home/ymzhang/guest/kallsyms \
| --guestmodules=/home/ymzhang/guest/modules top
|
|
| is very obvious even with a single guest. Now multiply that by more guests ...
|

For example we want 'perf kvm top' to do something useful by default: it
should find the first guest running and it should report its profile.

The tool shouldnt have to guess about where the guests are, what their
namespaces is and how to talk to them. We also want easy symbolic access to
guest, for example:

perf kvm -g OpenSuse-2 record sleep 1

I.e.:

- Easy default reference to guest instances, and a way for tools to
reference them symbolically as well in the multi-guest case. Preferably
something trustable and kernel-provided - not some indirect information
like a PID file created by libvirt-manager or so.

- Guest-transparent VFS integration into the host, to recover symbols and
debug info in binaries, etc.

There were a few responses to that but none really addressed those problems -
they mostly tried to re-define the problem and suggested that i was wrong to
want such capabilities and suggested various inferior approaches instead. See
the thread for the details - i think i covered every technical suggestion that
was made.

So we are still at an impasse as far as i can see. If i overlooked some
suggestion that addresses these problems then please let me know ...

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on

* Avi Kivity <avi(a)redhat.com> wrote:

> On 03/22/2010 04:32 PM, Ingo Molnar wrote:
> >* Avi Kivity<avi(a)redhat.com> wrote:
> >
> >>On 03/22/2010 02:44 PM, Ingo Molnar wrote:
> >>>This is why i consider that line of argument rather dishonest ...
> >>I am not going to reply to any more email from you on this thread.
> >Because i pointed out that i consider a line of argument intellectually
> >dishonest?
> >
> > I did not say _you_ as a person are dishonest - doing that would be an ad
> > honimen attack against your person. (In fact i dont think you are, to the
> > contrary)
> >
> > An argument can certainly be labeled dishonest in a fair discussion and it
> > is not a personal attack against you to express my opinion about that.
> >
>
> Sigh, why am I drawn into this.
>
> A person who uses dishonest arguments is a dishonest person. [...]

That's not how i understood that phrase - and i did not mean to suggest that
you are dishonest and i do not think that you are dishonest (to the contrary).

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/