diff for duplicates of <1373408783.8183.208@snotra> diff --git a/a/1.txt b/N1/1.txt index e9adc82..f9e995d 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,72 +1,72 @@ On 07/09/2013 05:00:26 PM, Alexander Graf wrote: -> +>=20 > On 09.07.2013, at 23:54, Scott Wood wrote: -> +>=20 > > On 07/09/2013 04:49:32 PM, Alexander Graf wrote: -> >> Not sure I understand. What the timing stats do is that they -> measure the time between [exit ... entry], right? We'd do the same -> thing, just all in C code. That means we would become slightly less -> accurate, but gain dynamic enabling of the traces and get rid of all +> >> Not sure I understand. What the timing stats do is that they =20 +> measure the time between [exit ... entry], right? We'd do the same =20 +> thing, just all in C code. That means we would become slightly less =20 +> accurate, but gain dynamic enabling of the traces and get rid of all =20 > the timing stat asm code. > > -> > Compile-time enabling bothers me less than a loss of accuracy (not -> just a small loss by moving into C code, but a potential for a large +> > Compile-time enabling bothers me less than a loss of accuracy (not =20 +> just a small loss by moving into C code, but a potential for a large =20 > loss if we overflow the buffer) -> +>=20 > Then don't overflow the buffer. Make it large enough. -How large is that? Does the tool recognize and report when overflow +How large is that? Does the tool recognize and report when overflow =20 happens? -How much will the overhead of running some python script on the host, +How much will the overhead of running some python script on the host, =20 consuming a large volume of data, affect the results? -> IIRC ftrace improved recently to dynamically increase the buffer size +> IIRC ftrace improved recently to dynamically increase the buffer size =20 > too. -> +>=20 > Steven, do I remember correctly here? Yay more complexity. -So now we get to worry about possible memory allocations happening when -we try to log something? Or if there is a way to do an "atomic" log, +So now we get to worry about possible memory allocations happening when =20 +we try to log something? Or if there is a way to do an "atomic" log, =20 we're back to the "buffer might be full" situation. > > and a dependency on a userspace tool -> -> We already have that for kvm_stat. It's a simple python script - and +>=20 +> We already have that for kvm_stat. It's a simple python script - and =20 > you surely have python on your rootfs, no? -> -> > (both in terms of the tool needing to be written, and in the hassle -> of ensuring that it's present in the root filesystem of whatever -> system I'm testing). And the whole mechanism will be more +>=20 +> > (both in terms of the tool needing to be written, and in the hassle =20 +> of ensuring that it's present in the root filesystem of whatever =20 +> system I'm testing). And the whole mechanism will be more =20 > complicated. -> -> It'll also be more flexible at the same time. You could take the logs -> and actually check what's going on to debug issues that you're +>=20 +> It'll also be more flexible at the same time. You could take the logs =20 +> and actually check what's going on to debug issues that you're =20 > encountering for example. -> -> We could even go as far as sharing the same tool with other +>=20 +> We could even go as far as sharing the same tool with other =20 > architectures, so that we only have to learn how to debug things once. -Have you encountered an actual need for this flexibility, or is it +Have you encountered an actual need for this flexibility, or is it =20 theoretical? -Is there common infrastructure for dealing with measuring intervals and -tracking statistics thereof, rather than just tracking points and -letting userspace connect the dots (though it could still do that as an -option)? Even if it must be done in userspace, it doesn't seem like +Is there common infrastructure for dealing with measuring intervals and =20 +tracking statistics thereof, rather than just tracking points and =20 +letting userspace connect the dots (though it could still do that as an =20 +option)? Even if it must be done in userspace, it doesn't seem like =20 something that should be KVM-specific. -> > Lots of debug options are enabled at build time; why must this be +> > Lots of debug options are enabled at build time; why must this be =20 > different? -> -> Because I think it's valuable as debug tool for cases where compile -> time switches are not the best way of debugging things. It's not a -> high profile thing to tackle for me tbh, but I don't really think -> working heavily on the timing stat thing is the correct path to walk +>=20 +> Because I think it's valuable as debug tool for cases where compile =20 +> time switches are not the best way of debugging things. It's not a =20 +> high profile thing to tackle for me tbh, but I don't really think =20 +> working heavily on the timing stat thing is the correct path to walk =20 > along. Adding new exit types isn't "working heavily" on it. --Scott +-Scott= diff --git a/a/content_digest b/N1/content_digest index c77e90a..acdf606 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,86 +1,86 @@ "ref\0B31BC4F4-39E8-479D-B5AB-2D7F870E7A6C@suse.de\0" "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [PATCH 2/2] KVM: PPC: Book3E: Emulate MCSRR0/1 SPR and rfmci instruction\0" - "Date\0Tue, 09 Jul 2013 22:26:23 +0000\0" + "Date\0Tue, 9 Jul 2013 17:26:23 -0500\0" "To\0Alexander Graf <agraf@suse.de>\0" - "Cc\0Mihai Caraman <mihai.caraman@freescale.com>" - <kvm-ppc@vger.kernel.org> <kvm-ppc@vger.kernel.org> - <kvm@vger.kernel.org> list <kvm@vger.kernel.org> + "Cc\0Steven Rostedt <rostedt@goodmis.org>" + Mihai Caraman <mihai.caraman@freescale.com> linuxppc-dev@lists.ozlabs.org - " Steven Rostedt <rostedt@goodmis.org>\0" + <kvm@vger.kernel.org> list <kvm@vger.kernel.org> + " <kvm-ppc@vger.kernel.org> <kvm-ppc@vger.kernel.org>\0" "\00:1\0" "b\0" "On 07/09/2013 05:00:26 PM, Alexander Graf wrote:\n" - "> \n" + ">=20\n" "> On 09.07.2013, at 23:54, Scott Wood wrote:\n" - "> \n" + ">=20\n" "> > On 07/09/2013 04:49:32 PM, Alexander Graf wrote:\n" - "> >> Not sure I understand. What the timing stats do is that they \n" - "> measure the time between [exit ... entry], right? We'd do the same \n" - "> thing, just all in C code. That means we would become slightly less \n" - "> accurate, but gain dynamic enabling of the traces and get rid of all \n" + "> >> Not sure I understand. What the timing stats do is that they =20\n" + "> measure the time between [exit ... entry], right? We'd do the same =20\n" + "> thing, just all in C code. That means we would become slightly less =20\n" + "> accurate, but gain dynamic enabling of the traces and get rid of all =20\n" "> the timing stat asm code.\n" "> >\n" - "> > Compile-time enabling bothers me less than a loss of accuracy (not \n" - "> just a small loss by moving into C code, but a potential for a large \n" + "> > Compile-time enabling bothers me less than a loss of accuracy (not =20\n" + "> just a small loss by moving into C code, but a potential for a large =20\n" "> loss if we overflow the buffer)\n" - "> \n" + ">=20\n" "> Then don't overflow the buffer. Make it large enough.\n" "\n" - "How large is that? Does the tool recognize and report when overflow \n" + "How large is that? Does the tool recognize and report when overflow =20\n" "happens?\n" "\n" - "How much will the overhead of running some python script on the host, \n" + "How much will the overhead of running some python script on the host, =20\n" "consuming a large volume of data, affect the results?\n" "\n" - "> IIRC ftrace improved recently to dynamically increase the buffer size \n" + "> IIRC ftrace improved recently to dynamically increase the buffer size =20\n" "> too.\n" - "> \n" + ">=20\n" "> Steven, do I remember correctly here?\n" "\n" "Yay more complexity.\n" "\n" - "So now we get to worry about possible memory allocations happening when \n" - "we try to log something? Or if there is a way to do an \"atomic\" log, \n" + "So now we get to worry about possible memory allocations happening when =20\n" + "we try to log something? Or if there is a way to do an \"atomic\" log, =20\n" "we're back to the \"buffer might be full\" situation.\n" "\n" "> > and a dependency on a userspace tool\n" - "> \n" - "> We already have that for kvm_stat. It's a simple python script - and \n" + ">=20\n" + "> We already have that for kvm_stat. It's a simple python script - and =20\n" "> you surely have python on your rootfs, no?\n" - "> \n" - "> > (both in terms of the tool needing to be written, and in the hassle \n" - "> of ensuring that it's present in the root filesystem of whatever \n" - "> system I'm testing). And the whole mechanism will be more \n" + ">=20\n" + "> > (both in terms of the tool needing to be written, and in the hassle =20\n" + "> of ensuring that it's present in the root filesystem of whatever =20\n" + "> system I'm testing). And the whole mechanism will be more =20\n" "> complicated.\n" - "> \n" - "> It'll also be more flexible at the same time. You could take the logs \n" - "> and actually check what's going on to debug issues that you're \n" + ">=20\n" + "> It'll also be more flexible at the same time. You could take the logs =20\n" + "> and actually check what's going on to debug issues that you're =20\n" "> encountering for example.\n" - "> \n" - "> We could even go as far as sharing the same tool with other \n" + ">=20\n" + "> We could even go as far as sharing the same tool with other =20\n" "> architectures, so that we only have to learn how to debug things once.\n" "\n" - "Have you encountered an actual need for this flexibility, or is it \n" + "Have you encountered an actual need for this flexibility, or is it =20\n" "theoretical?\n" "\n" - "Is there common infrastructure for dealing with measuring intervals and \n" - "tracking statistics thereof, rather than just tracking points and \n" - "letting userspace connect the dots (though it could still do that as an \n" - "option)? Even if it must be done in userspace, it doesn't seem like \n" + "Is there common infrastructure for dealing with measuring intervals and =20\n" + "tracking statistics thereof, rather than just tracking points and =20\n" + "letting userspace connect the dots (though it could still do that as an =20\n" + "option)? Even if it must be done in userspace, it doesn't seem like =20\n" "something that should be KVM-specific.\n" "\n" - "> > Lots of debug options are enabled at build time; why must this be \n" + "> > Lots of debug options are enabled at build time; why must this be =20\n" "> different?\n" - "> \n" - "> Because I think it's valuable as debug tool for cases where compile \n" - "> time switches are not the best way of debugging things. It's not a \n" - "> high profile thing to tackle for me tbh, but I don't really think \n" - "> working heavily on the timing stat thing is the correct path to walk \n" + ">=20\n" + "> Because I think it's valuable as debug tool for cases where compile =20\n" + "> time switches are not the best way of debugging things. It's not a =20\n" + "> high profile thing to tackle for me tbh, but I don't really think =20\n" + "> working heavily on the timing stat thing is the correct path to walk =20\n" "> along.\n" "\n" "Adding new exit types isn't \"working heavily\" on it.\n" "\n" - -Scott + -Scott= -47e20cd584c6db89e52c19964de9c3938433e38a96367bce03347b15728338ed +8edaa970c35a39d2884d5c3b48413d8da64bb80ff0ad48bbdc8060a192a21000
diff --git a/a/content_digest b/N2/content_digest index c77e90a..a2a4d73 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,12 +1,12 @@ "ref\0B31BC4F4-39E8-479D-B5AB-2D7F870E7A6C@suse.de\0" "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [PATCH 2/2] KVM: PPC: Book3E: Emulate MCSRR0/1 SPR and rfmci instruction\0" - "Date\0Tue, 09 Jul 2013 22:26:23 +0000\0" + "Date\0Tue, 9 Jul 2013 17:26:23 -0500\0" "To\0Alexander Graf <agraf@suse.de>\0" "Cc\0Mihai Caraman <mihai.caraman@freescale.com>" <kvm-ppc@vger.kernel.org> <kvm-ppc@vger.kernel.org> <kvm@vger.kernel.org> list <kvm@vger.kernel.org> - linuxppc-dev@lists.ozlabs.org + <linuxppc-dev@lists.ozlabs.org> " Steven Rostedt <rostedt@goodmis.org>\0" "\00:1\0" "b\0" @@ -83,4 +83,4 @@ "\n" -Scott -47e20cd584c6db89e52c19964de9c3938433e38a96367bce03347b15728338ed +b94e65256719d7691fc70820ef3849b42d808024eeab184d60a1ef7c7dbdcd85
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.