* Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-06-09 at 12:41 +0300, Avi Kivity wrote:
Disabling the watchdog is unfortunate. Why is it necessary?
perf always uses NMI, so we disable the nmi_watchdog when a perf_event is
set up in case they might have impact.
* Zhang, Yanmin yanmin_zh...@linux.intel.com wrote:
unsigned long perf_misc_flags(struct pt_regs *regs)
{
int misc = 0;
+
if (perf_guest_cbs perf_guest_cbs-is_in_guest()) {
+ if (perf_guest_cbs-is_user_mode())
+ misc |=
* Ingo Molnar mi...@elte.hu wrote:
* Zhang, Yanmin yanmin_zh...@linux.intel.com wrote:
unsigned long perf_misc_flags(struct pt_regs *regs)
{
int misc = 0;
+
if (perf_guest_cbs perf_guest_cbs-is_in_guest()) {
+ if (perf_guest_cbs-is_user_mode
* Zhang, Yanmin yanmin_zh...@linux.intel.com wrote:
Here is the new patch of V5 against tip/master of April 17th if anyone wants
to try it.
Ok, this looks pretty good from the perf angle - so once Avi likes patches #1
and #2 and creates a pullable branch we can apply #3 as well to
FYI, i found a few problems that need fixing:
+ unsigned long ip;
+ if (perf_guest_cbs perf_guest_cbs-is_in_guest())
missing newline.
+ int misc = 0;
+ if (perf_guest_cbs perf_guest_cbs-is_in_guest()) {
ditto.
+ PERF_RECORD_MISC_GUEST_KERNEL;
+
* Avi Kivity a...@redhat.com wrote:
On 04/17/2010 10:13 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 04/16/2010 10:34 AM, Zhang, Yanmin wrote:
Below is the kernel patch to enable perf to collect guest os statistics.
Joerg,
Would you like to add support on svm? I
* Avi Kivity a...@redhat.com wrote:
On 04/14/2030 12:05 PM, Zhang, Yanmin wrote:
Here is the new patch of V3 against tip/master of April 13th
if anyone wants to try it.
Thanks for persisting despite the flames.
Can you please separate arch/x86/kvm part of the patch? That will make
* oerg Roedel j...@8bytes.org wrote:
It can decide whether it exposes the files. Nor are there any security
issues to begin with.
I am not talking about security. [...]
You were talking about security, in the portion of your mail that you snipped
out, and which i replied to:
2.
* oerg Roedel j...@8bytes.org wrote:
On Sun, Mar 21, 2010 at 07:43:00PM +0100, Ingo Molnar wrote:
Having access to the actual executable files that include the symbols
achieves
precisely that - with the additional robustness that all this functionality
is
concentrated
* Avi Kivity 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
* Avi Kivity a...@redhat.com wrote:
On 03/21/2010 10:37 PM, Ingo Molnar wrote:
That includes the guest kernel. If you can deploy a new kernel in the
guest, presumably you can deploy a userspace package.
Note that with perf we can instrument the guest with zero guest-kernel
* Avi Kivity a...@redhat.com wrote:
My 10+ years experience with kernel instrumentation solutions is that
kernel-driven, self-sufficient, robust, trustable, well-enumerated sources
of information work far better in practice.
What about line number information? And the source? Into
* Anthony Liguori anth...@codemonkey.ws wrote:
On 03/21/2010 04:54 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/21/2010 10:55 PM, Ingo Molnar wrote:
Of course you could say the following:
' Thanks, I'll mark this for v2.6.36 integration. Note that we
* oerg Roedel j...@8bytes.org wrote:
On Sun, Mar 21, 2010 at 09:31:21PM +0100, Ingo Molnar wrote:
Lets see one example of that thought process in action: Oprofile.
Since you are talking so much about oProfile in this thread I think it is
important to mention that the problem
* Joerg Roedel j...@8bytes.org wrote:
On Mon, Mar 22, 2010 at 11:59:27AM +0100, Ingo Molnar wrote:
Best would be if you demonstrated any problems of the perf symbol lookup
code
you are aware of on the host side, as it has that exact design you are
criticising here. We are eager
* Avi Kivity a...@redhat.com wrote:
On 03/22/2010 01:14 PM, Ingo Molnar wrote:
I think we agree at last. Neither I nor my employer are interested in
running qemu as a desktop-on-desktop tool, therefore I don't invest any
effort in that direction, or require it from volunteers.
Obviously
* Daniel P. Berrange berra...@redhat.com wrote:
On Mon, Mar 22, 2010 at 02:31:49PM +0200, Pekka Enberg wrote:
On Mon, Mar 22, 2010 at 1:48 PM, Ingo Molnar mi...@elte.hu wrote:
What about line number information? ?And the source? ?Into the kernel
with
them as well?
Sigh. Please
* Daniel P. Berrange berra...@redhat.com wrote:
On Mon, Mar 22, 2010 at 01:54:40PM +0100, Ingo Molnar wrote:
* Daniel P. Berrange berra...@redhat.com wrote:
FYI, for offline guests, you can use libguestfs[1] to access change
files
inside the guest, and read-only access
* Richard W.M. Jones rjo...@redhat.com wrote:
On Mon, Mar 22, 2010 at 01:05:13PM +, Daniel P. Berrange wrote:
This is close to the way libguestfs already works. It boots QEMU/KVM
pointing
to a minimal stripped down appliance linux OS image, containing a small
agent
it talks to
* Richard W.M. Jones rjo...@redhat.com wrote:
On Mon, Mar 22, 2010 at 02:56:47PM +0100, Ingo Molnar wrote:
Just curious: any plans to extend this to include live read/write access as
well?
I.e. to have the 'agent' (guestfsd) running universally, so that
tools such as perf
* Avi Kivity a...@redhat.com wrote:
On 03/22/2010 01:39 PM, Ingo Molnar wrote:
Reality is, the server space never was and never will be self-sustaining
in the long run (as Novell has found it out with Netware), it is the
desktop that dictates future markets. This is why i find your
* Avi Kivity 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
* Avi Kivity a...@redhat.com wrote:
On 03/22/2010 01:23 PM, Ingo Molnar wrote:
* Avi Kivitya...@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
* Pekka Enberg penb...@cs.helsinki.fi wrote:
Hi Avi,
On Mon, Mar 22, 2010 at 2:49 PM, Avi Kivity 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
* Anthony Liguori anth...@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
* Avi Kivity a...@redhat.com wrote:
On 03/22/2010 04:32 PM, Ingo Molnar wrote:
* Avi Kivitya...@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
.
On Mon, Mar 22, 2010 at 01:22:28PM +0100, Ingo Molnar wrote:
* Joerg Roedel j...@8bytes.org wrote:
[...] Basically the reason of the oProfile failure is a disfunctional
community. [...]
Caused by: repository separation and the inevitable code and social fork a
decade later
* Avi Kivity a...@redhat.com wrote:
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 \
|
* Anthony Liguori anth...@codemonkey.ws wrote:
On 03/22/2010 10:55 AM, Ingo Molnar wrote:
* Anthony Liguorianth...@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
* Anthony Liguori anth...@codemonkey.ws wrote:
- 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
* Avi Kivity a...@redhat.com wrote:
- 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
* Avi Kivity a...@redhat.com wrote:
On 03/22/2010 07:27 PM, Pekka Enberg wrote:
It's kinda funny to see people argue that having an external repository is
not a problem and that it's not a big deal if building something from the
repository is slightly painful as long as it doesn't
* Pekka Enberg penb...@cs.helsinki.fi wrote:
Hi Frank,
On Mon, Mar 22, 2010 at 7:17 PM, Frank Ch. Eigler f...@redhat.com wrote:
In your very previous paragraphs, you enumerate two separate causes:
repository structure and development/maintenance process as being
sources of fun. ?Please
* Avi Kivity a...@redhat.com wrote:
On 03/22/2010 06:32 PM, Ingo Molnar wrote:
So, what do you think creates code communities and keeps them alive?
Developers and code. And the wellbeing of developers are primarily
influenced by the repository structure and by the development
* Avi Kivity a...@redhat.com wrote:
Lets look at the ${HOME}/.qemu/qmp/ enumeration method suggested by
Anthony. There's numerous ways that this can break:
I don't like it either. We have libvirt for enumerating guests.
Which has pretty much the same problems to the ${HOME}/.qemu/qmp/
* Anthony Liguori anth...@codemonkey.ws wrote:
On 03/22/2010 12:34 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
- Easy default reference to guest instances, and a way for tools to
reference them symbolically as well in the multi-guest case.
Preferably
something
* Anthony Liguori anth...@codemonkey.ws wrote:
On 03/22/2010 12:34 PM, Ingo Molnar wrote:
This is really just the much-discredited microkernel approach for keeping
global enumeration data that should be kept by the kernel ...
Lets look at the ${HOME}/.qemu/qmp/ enumeration method suggested
* Joerg Roedel j...@8bytes.org wrote:
On Mon, Mar 22, 2010 at 05:32:15PM +0100, Ingo Molnar wrote:
I dont know how you can find the situation of Alpha comparable, which is a
legacy architecture for which no new CPU was manufactored in the past ~10
years.
The negative effects
* Alexander Graf ag...@suse.de wrote:
Yes. I think the point was that every layer in between brings potential
slowdown and loss of features.
Exactly. The more 'fragmented' a project is into sub-projects, without a
single, unified, functional reference implementation in the center of it, the
* Alexander Graf ag...@suse.de wrote:
Furthermore, another negative effect is that many times features are
implemented not in their technically best way, but in a way to keep them
local to the project that originates them. This is done to keep deployment
latencies and general
* Avi Kivity a...@redhat.com wrote:
I think you didnt understand my point. I am talking about 'perf kvm top'
hanging if Qemu hangs.
Use non-blocking I/O, report that guest as dead. No point in profiling it,
it isn't making any progress.
Erm, at what point do i decide that a guest is
* Anthony Liguori anth...@codemonkey.ws wrote:
On 03/22/2010 02:22 PM, Ingo Molnar wrote:
Transitive had a product that was using a KVM context to run their
binary translator which allowed them full access to the host
processes virtual address space range. In this case, there is no
kernel
* Avi Kivity a...@redhat.com wrote:
On 03/22/2010 09:22 PM, Ingo Molnar wrote:
Transitive had a product that was using a KVM context to run their binary
translator which allowed them full access to the host processes virtual
address space range. In this case, there is no kernel
* Avi Kivity a...@redhat.com wrote:
On 03/22/2010 09:27 PM, Ingo Molnar wrote:
If your position basically boils down to, we can't trust userspace
and we can always trust the kernel, I want to eliminate any
userspace path, then I can't really help you out.
Why would you want to 'help
* oerg Roedel j...@8bytes.org wrote:
On Fri, Mar 19, 2010 at 09:21:22AM +0100, Ingo Molnar wrote:
Unfortunately, in a previous thread the Qemu maintainer has indicated that
he
will essentially NAK any attempt to enhance Qemu to provide an easily
discoverable, self-contained
* Avi Kivity a...@redhat.com wrote:
[...] Second, from my point of view all contributors are volunteers
(perhaps their employer volunteered them, but there's no difference from
my perspective). Asking them to repaint my apartment as a condition to
get a patch applied is abuse. If a
* Anthony Liguori anth...@codemonkey.ws wrote:
On 03/19/2010 03:53 AM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
There were two negative reactions immediately, both showed a fundamental
server versus desktop bias:
- you did not accept that the most important usecase
* Antoine Martin anto...@nagafix.co.uk wrote:
On 03/22/2010 02:17 AM, Ingo Molnar wrote:
* Anthony Liguorianth...@codemonkey.ws wrote:
On 03/19/2010 03:53 AM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
There were two negative reactions immediately, both showed a fundamental
* Avi Kivity a...@redhat.com wrote:
On 03/21/2010 09:17 PM, Ingo Molnar wrote:
Adding any new daemon to an existing guest is a deployment and usability
nightmare.
The logical conclusion of that is that everything should be built into the
kernel. [...]
Only if you apply
* Avi Kivity a...@redhat.com wrote:
On 03/21/2010 10:08 PM, Olivier Galibert wrote:
On Sun, Mar 21, 2010 at 10:01:51PM +0200, Avi Kivity wrote:
On 03/21/2010 09:17 PM, Ingo Molnar wrote:
Adding any new daemon to an existing guest is a deployment and usability
nightmare.
The logical
* Avi Kivity a...@redhat.com wrote:
On 03/21/2010 09:06 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
[...] Second, from my point of view all contributors are volunteers
(perhaps their employer volunteered them, but there's no difference from
my perspective). Asking them
* Avi Kivity a...@redhat.com wrote:
On 03/21/2010 09:59 PM, Ingo Molnar wrote:
Frankly, i was surprised (and taken slightly off base) by both Avi and
Anthony
suggesting such a clearly inferior add a demon to the guest space solution.
It's a usability and deployment non-starter.
It's
* Avi Kivity a...@redhat.com wrote:
Well, for what it's worth, I rarely ever use anything else. My virtual
disks are raw so I can loop mount them easily, and I can also switch my
guest kernels from outside... without ever needing to mount those disks.
Curious, what do you use them
* Avi Kivity a...@redhat.com wrote:
I.e. you are arguing for microkernel Linux, while you see me as arguing
for a monolithic kernel.
No. I'm arguing for reducing bloat wherever possible. Kernel code is more
expensive than userspace code in every metric possible.
1)
One of the
* Avi Kivity a...@redhat.com wrote:
On 03/21/2010 10:55 PM, Ingo Molnar wrote:
Of course you could say the following:
' Thanks, I'll mark this for v2.6.36 integration. Note that we are not
able to add this to the v2.6.35 kernel queue anymore as the ongoing
usability work
* Avi Kivity a...@redhat.com wrote:
Consider the _other_ examples that are a lot more clear:
' If you expose paravirt spilocks via KVM please also make sure the KVM
tooling can make use of it, has an option for it to configure it, and
that it has sufficient efficiency
Nice progress!
This bit:
1) perf kvm top
[r...@lkp-ne01 norm]# perf kvm --host --guest
--guestkallsyms=/home/ymzhang/guest/kallsyms
--guestmodules=/home/ymzhang/guest/modules top
Will be really be painful to developers - to enter that long line while we
have these things called
* Avi Kivity a...@redhat.com wrote:
There were two negative reactions immediately, both showed a fundamental
server versus desktop bias:
- you did not accept that the most important usecase is when there is a
single guest running.
Well, it isn't.
Erm, my usability points are
* Zhang, Yanmin yanmin_zh...@linux.intel.com wrote:
I worked out 3 new patches against tip/master tree of Mar. 17th.
Cool! Mind sending them as a series of patches instead of attachment? That
makes it easier to review them. Also, the Signed-off-by lines seem to be
missing plus we need a per
* Avi Kivity a...@redhat.com wrote:
On 03/17/2010 10:10 AM, Ingo Molnar wrote:
It's about who owns the user interface.
If qemu owns the user interface, than we can satisfy this in a very
simple way by adding a perf monitor command. If we have to support third
party tools
* Avi Kivity a...@redhat.com wrote:
- move a clean (and minimal) version of the Qemu code base to tools/kvm/,
in the upstream kernel repo, and work on that from that point on.
I'll ignore the repository location which should be immaterial to a serious
developer and concentrate on
* Alexander Graf ag...@suse.de wrote:
On 18.03.2010, at 09:56, Ingo Molnar wrote:
* Avi Kivity a...@redhat.com wrote:
On 03/17/2010 10:10 AM, Ingo Molnar wrote:
It's about who owns the user interface.
If qemu owns the user interface, than we can satisfy this in a very
* Avi Kivity a...@redhat.com wrote:
On 03/18/2010 10:56 AM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/17/2010 10:10 AM, Ingo Molnar wrote:
It's about who owns the user interface.
If qemu owns the user interface, than we can satisfy this in a very
simple way by adding
* Avi Kivity a...@redhat.com wrote:
The moment any change (be it as trivial as fixing a GUI detail or as
complex as a new feature) involves two or more packages, development speed
slows down to a crawl - while the complexity of the change might be very
low!
Why is that?
It's very
* Jes Sorensen jes.soren...@redhat.com wrote:
On 03/18/10 10:54, Ingo Molnar wrote:
* Jes Sorensenjes.soren...@redhat.com wrote:
[...]
At my previous employer we ended up dropping all Xen efforts exactly because
it was like maintaining two separate operating system kernels. The key
* Avi Kivity a...@redhat.com wrote:
On 03/18/2010 11:22 AM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
- move a clean (and minimal) version of the Qemu code base to tools/kvm/,
in the upstream kernel repo, and work on that from that point on.
I'll ignore the repository
* Avi Kivity a...@redhat.com wrote:
On 03/18/2010 12:50 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
The moment any change (be it as trivial as fixing a GUI detail or as
complex as a new feature) involves two or more packages, development speed
slows down to a crawl - while
* Avi Kivity a...@redhat.com wrote:
On 03/18/2010 01:48 PM, Ingo Molnar wrote:
It's not inevitable, if the projects are badly run, you'll have high
latencies, but projects don't have to be badly run.
So the 64K dollar question is, why does Qemu still suck?
Where people sent
* Frank Ch. Eigler f...@redhat.com wrote:
Ingo Molnar mi...@elte.hu writes:
[...]
Distributions are very eager to update kernels even in stable periods of
the
distro lifetime - they are much less willing to update user-space packages.
[...]
Sorry, er, what? What distributions
* Avi Kivity a...@redhat.com wrote:
On 03/18/2010 03:02 PM, Ingo Molnar wrote:
[...] What users eagerly replace their kernels?
Those 99% who click on the 'install 193 updates' popup.
Of which 1 is the kernel, and 192 are userspace updates (of which one may be
qemu).
I think you
* Frank Ch. Eigler f...@redhat.com wrote:
Hi -
[...]
Distributions are very eager to update kernels even in stable periods
of the
distro lifetime - they are much less willing to update user-space
packages.
[...]
Sorry, er, what? What distributions eagerly
* Avi Kivity a...@redhat.com wrote:
On 03/18/2010 03:31 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/18/2010 03:02 PM, Ingo Molnar wrote:
[...] What users eagerly replace their kernels?
Those 99% who click on the 'install 193 updates' popup.
Of which 1 is the kernel
* Daniel P. Berrange berra...@redhat.com wrote:
On Thu, Mar 18, 2010 at 02:31:24PM +0100, Ingo Molnar wrote:
* Avi Kivity a...@redhat.com wrote:
On 03/18/2010 03:02 PM, Ingo Molnar wrote:
[...] What users eagerly replace their kernels?
Those 99% who click
* Avi Kivity a...@redhat.com wrote:
That is not what i said. I said they are closely related, and where
technologies are closely related, project proximity turns into project
unification at a certain stage.
I really don't see how. So what if both qemu and kvm implement an i8254?
* John Kacur jka...@redhat.com wrote:
On Thu, Mar 18, 2010 at 2:59 PM, Ingo Molnar mi...@elte.hu wrote:
* Daniel P. Berrange berra...@redhat.com wrote:
On Thu, Mar 18, 2010 at 02:31:24PM +0100, Ingo Molnar wrote:
* Avi Kivity a...@redhat.com wrote:
On 03/18/2010 03:02 PM
* John Kacur jka...@redhat.com wrote:
On Thu, Mar 18, 2010 at 1:33 PM, Frank Ch. Eigler f...@redhat.com wrote:
Ingo Molnar mi...@elte.hu writes:
[...]
Distributions are very eager to update kernels even in stable periods of
the
distro lifetime - they are much less willing to update
* Anthony Liguori anth...@codemonkey.ws wrote:
On 03/18/2010 08:00 AM, Ingo Molnar wrote:
[...] kvm in fact knows nothing about vga, to take your last example.
[...]
Look at the VGA dirty bitmap optimization a'ka the KVM_GET_DIRTY_LOG
ioctl.
See qemu/kvm-all.c's
* Jes Sorensen jes.soren...@redhat.com wrote:
On 03/18/10 15:22, Ingo Molnar wrote:
* Jes Sorensenjes.soren...@redhat.com wrote:
Both perf and oprofile are still relatively small projects in comparison to
QEMU.
So is your argument that the unification does not make sense due to size
* Pekka Enberg penb...@cs.helsinki.fi wrote:
On Thu, Mar 18, 2010 at 6:38 PM, Anthony Liguori anth...@codemonkey.ws
wrote:
There are all kernel space projects, going through Xorg would be a
horrible waste of performance for full-screen virtualization. It's fine
for the windowed or
* Avi Kivity a...@redhat.com wrote:
On 03/18/2010 06:13 PM, Ingo Molnar wrote:
Currently there's a wall between kernel developers and user-space
developers, and there's somewhat of an element of fear and arrogance on
both sides. For efficient technology such walls needs torn down
* Avi Kivity a...@redhat.com wrote:
On 03/18/2010 04:09 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
That is not what i said. I said they are closely related, and where
technologies are closely related, project proximity turns into project
unification at a certain stage
* Avi Kivity a...@redhat.com wrote:
On 03/18/2010 07:02 PM, Ingo Molnar wrote:
I find the 'KVM mostly cares about the server, not about the desktop'
attitude expressed in this thread troubling.
It's not kvm, just it's developers (and their employers, where applicable).
If you post
* Anthony Liguori anth...@codemonkey.ws wrote:
On 03/18/2010 10:17 AM, Ingo Molnar wrote:
* Anthony Liguorianth...@codemonkey.ws wrote:
On 03/18/2010 08:00 AM, Ingo Molnar wrote:
[...] kvm in fact knows nothing about vga, to take your last example.
[...]
Look at the VGA dirty bitmap
* Anthony Liguori anth...@codemonkey.ws wrote:
On 03/18/2010 06:48 AM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/18/2010 12:50 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
The moment any change (be it as trivial as fixing a GUI detail or as
complex
* drep...@gmail.com drep...@gmail.com wrote:
On Thu, Mar 18, 2010 at 09:13, Ingo Molnar mi...@elte.hu wrote:
The suckage of kernel async IO is for similar reasons: there's an ugly
package separation problem between the kernel and between glibc
Bollocks. glibc would use (and is using
* drep...@gmail.com drep...@gmail.com wrote:
On Thu, Mar 18, 2010 at 12:15, Ingo Molnar mi...@elte.hu wrote:
I didnt say it's glibc's fault - if then it's more of the kernel's fault
as most of the complexity is on that side. I said it's due to the
fundamental distance between the app
* Frank Ch. Eigler f...@redhat.com wrote:
Frederic Weisbecker fweis...@gmail.com writes:
[...] It is actually because both kernel and user side are sync in this
scheme. [...]
This argues that co-evolution of an interface is easiest on the developers
if they own both sides of that
* drep...@gmail.com drep...@gmail.com wrote:
For example, just to state the obvious: libaio has been written 8 years
ago in 2002 and has been used in apps early on. Why arent those kernel
APIs, while not being a full/complete solution, supported by glibc, and
wrapped to pthreads based
* Zachary Amsden zams...@redhat.com wrote:
On 03/18/2010 12:50 AM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
The moment any change (be it as trivial as fixing a GUI detail or as
complex as a new feature) involves two or more packages, development speed
slows down to a crawl
* Alan Cox a...@lxorguk.ukuu.org.uk wrote:
So it's good enough to be in Fedora/RHEL but not good enough to be in
upstream glibc? How is that possible? Isnt that a double standard?
Yes its a double standard
Glibc has a higher standard than Fedora/RHEL.
Just like the Ubuntu kernel
* Zachary Amsden zams...@redhat.com wrote:
On 03/18/2010 11:15 AM, Ingo Molnar wrote:
* Zachary Amsdenzams...@redhat.com wrote:
On 03/18/2010 12:50 AM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
The moment any change (be it as trivial as fixing a GUI detail or as
complex
* oerg Roedel j...@8bytes.org wrote:
On Tue, Mar 16, 2010 at 12:25:00PM +0100, Ingo Molnar wrote:
Hm, that sounds rather messy if we want to use it to basically expose
kernel
functionality in a guest/host unified way. Is the qemu process discoverable
in
some secure way? Can we
* Anthony Liguori anth...@codemonkey.ws wrote:
On 03/16/2010 12:39 PM, Ingo Molnar wrote:
If we look at the use-case, it's going to be something like, a user is
creating virtual machines and wants to get performance information about
them.
Having to run a separate tool like perf
* Frank Ch. Eigler f...@redhat.com wrote:
Hi -
On Tue, Mar 16, 2010 at 06:04:10PM -0500, Anthony Liguori wrote:
[...]
The only way to really address this is to change the interaction.
Instead of running perf externally to qemu, we should support a perf
command in the qemu monitor
* Avi Kivity a...@redhat.com wrote:
Monitoring guests from the host is useful for kvm developers, but less so
for users.
Guest space profiling is easy, and 'perf kvm' is not about that. (plain 'perf'
will work if a proper paravirt channel is opened to the host)
I think you might have
* Anthony Liguori aligu...@linux.vnet.ibm.com wrote:
If you want to use a synthetic filesystem as the management interface for
qemu, that's one thing. But you suggested exposing the guest filesystem in
its entirely and that's what I disagreed with.
What did you think, that it would be
* Avi Kivity a...@redhat.com wrote:
On 03/17/2010 10:16 AM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
Monitoring guests from the host is useful for kvm developers, but less so
for users.
Guest space profiling is easy, and 'perf kvm' is not about that. (plain
'perf
* Avi Kivity a...@redhat.com wrote:
On 03/16/2010 07:27 AM, Zhang, Yanmin wrote:
From: Zhang, Yanminyanmin_zh...@linux.intel.com
Based on the discussion in KVM community, I worked out the patch to support
perf to collect guest os statistics from host side. This patch is implemented
with
* Zhang, Yanmin yanmin_zh...@linux.intel.com wrote:
On Tue, 2010-03-16 at 15:48 +0800, Zhang, Yanmin wrote:
On Tue, 2010-03-16 at 07:41 +0200, Avi Kivity wrote:
On 03/16/2010 07:27 AM, Zhang, Yanmin wrote:
From: Zhang, Yanminyanmin_zh...@linux.intel.com
Based on the discussion
* Avi Kivity a...@redhat.com wrote:
On 03/16/2010 09:24 AM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/16/2010 07:27 AM, Zhang, Yanmin wrote:
From: Zhang, Yanminyanmin_zh...@linux.intel.com
Based on the discussion in KVM community, I worked out the patch to support
401 - 500 of 617 matches
Mail list logo
