Prev: Irish 2010 Grant Winner
Next: [PATCH] staging: winbond: mds_f.h whitespace and CamelCase corrections.
From: Avi Kivity on 22 Mar 2010 10:50 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 22 Mar 2010 10:50 * 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 22 Mar 2010 11:00 * 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 22 Mar 2010 12:00 * 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 22 Mar 2010 12:10
* 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/ |