diff for duplicates of <1373406891.8183.207@snotra> diff --git a/a/1.txt b/N1/1.txt index 232d163..cbddcdd 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,27 +1,27 @@ On 07/09/2013 04:49:32 PM, Alexander Graf wrote: -> +>=20 > On 09.07.2013, at 20:29, Scott Wood wrote: -> +>=20 > > On 07/09/2013 12:46:32 PM, Alexander Graf wrote: > >> On 07/09/2013 07:16 PM, Scott Wood wrote: > >>> On 07/08/2013 01:45:58 PM, Alexander Graf wrote: > >>>> On 03.07.2013, at 15:30, Mihai Caraman wrote: -> >>>> > Some guests are making use of return from machine check +> >>>> > Some guests are making use of return from machine check =20 > instruction -> >>>> > to do crazy things even though the 64-bit kernel doesn't +> >>>> > to do crazy things even though the 64-bit kernel doesn't =20 > handle yet -> >>>> > this interrupt. Emulate MCSRR0/1 SPR and rfmci instruction +> >>>> > this interrupt. Emulate MCSRR0/1 SPR and rfmci instruction =20 > accordingly. > >>>> > > >>>> > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com> > >>>> > --- > >>>> > arch/powerpc/include/asm/kvm_host.h | 1 + -> >>>> > arch/powerpc/kvm/booke_emulate.c | 25 +> >>>> > arch/powerpc/kvm/booke_emulate.c | 25 =20 > +++++++++++++++++++++++++ > >>>> > arch/powerpc/kvm/timing.c | 1 + > >>>> > 3 files changed, 27 insertions(+), 0 deletions(-) > >>>> > -> >>>> > diff --git a/arch/powerpc/include/asm/kvm_host.h +> >>>> > diff --git a/arch/powerpc/include/asm/kvm_host.h =20 > b/arch/powerpc/include/asm/kvm_host.h > >>>> > index af326cd..0466789 100644 > >>>> > --- a/arch/powerpc/include/asm/kvm_host.h @@ -31,44 +31,44 @@ On 07/09/2013 04:49:32 PM, Alexander Graf wrote: > >>>> > EMULATED_RFI_EXITS, > >>>> > EMULATED_RFCI_EXITS, > >>>> > + EMULATED_RFMCI_EXITS, -> >>>> I would quite frankly prefer to see us abandon the whole exit -> timing framework in the kernel and instead use trace points. Then we +> >>>> I would quite frankly prefer to see us abandon the whole exit =20 +> timing framework in the kernel and instead use trace points. Then we =20 > don't have to maintain all of this randomly exercised code. -> >>> Would this map well to tracepoints? We're not trying to track +> >>> Would this map well to tracepoints? We're not trying to track =20 > discrete events, so much as accumulated time spent in different areas. -> >> I think so. We'd just have to emit tracepoints as soon as we enter -> handle_exit and in prepare_to_enter. Then a user space program should -> have everything it needs to create statistics out of that. It would +> >> I think so. We'd just have to emit tracepoints as soon as we enter =20 +> handle_exit and in prepare_to_enter. Then a user space program should =20 +> have everything it needs to create statistics out of that. It would =20 > certainly simplify the entry/exit path. > > > > I was hoping that wasn't going to be your answer. :-) > > -> > Such a change would introduce a new dependency, more complexity, -> and the possibility for bad totals to result from a ring buffer +> > Such a change would introduce a new dependency, more complexity, =20 +> and the possibility for bad totals to result from a ring buffer =20 > filling faster than userspace can drain it. -> -> Well, at least it would allow for optional tracing :). Today you have +>=20 +> Well, at least it would allow for optional tracing :). Today you have =20 > to change a compile flag to enable / disable timing stats. -> +>=20 > > -> > I also don't see how it would simplify entry/exit, since we'd still -> need to take timestamps in the same places, in order to record a +> > I also don't see how it would simplify entry/exit, since we'd still =20 +> need to take timestamps in the same places, in order to record a =20 > final event that says how long a particular event took. -> -> 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 +>=20 +> Not sure I understand. What the timing stats do is that they measure =20 +> the time between [exit ... entry], right? We'd do the same thing, =20 +> 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 loss if -we overflow the buffer) and a dependency on a userspace tool (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 +Compile-time enabling bothers me less than a loss of accuracy (not just =20 +a small loss by moving into C code, but a potential for a large loss if =20 +we overflow the buffer) and a dependency on a userspace tool (both in =20 +terms of the tool needing to be written, and in the hassle of ensuring =20 +that it's present in the root filesystem of whatever system I'm =20 testing). And the whole mechanism will be more complicated. -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? --Scott +-Scott= diff --git a/a/content_digest b/N1/content_digest index 9cc2e25..41b2384 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -7,38 +7,38 @@ "ref\0822D94B1-6E7E-4416-9F34-72E3BEAF6B8F@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 21:54:51 +0000\0" + "Date\0Tue, 9 Jul 2013 16:54:51 -0500\0" "To\0Alexander Graf <agraf@suse.de>\0" "Cc\0Mihai Caraman <mihai.caraman@freescale.com>" - kvm-ppc@vger.kernel.org + linuxppc-dev@lists.ozlabs.org kvm@vger.kernel.org - " linuxppc-dev@lists.ozlabs.org\0" + " kvm-ppc@vger.kernel.org\0" "\00:1\0" "b\0" "On 07/09/2013 04:49:32 PM, Alexander Graf wrote:\n" - "> \n" + ">=20\n" "> On 09.07.2013, at 20:29, Scott Wood wrote:\n" - "> \n" + ">=20\n" "> > On 07/09/2013 12:46:32 PM, Alexander Graf wrote:\n" "> >> On 07/09/2013 07:16 PM, Scott Wood wrote:\n" "> >>> On 07/08/2013 01:45:58 PM, Alexander Graf wrote:\n" "> >>>> On 03.07.2013, at 15:30, Mihai Caraman wrote:\n" - "> >>>> > Some guests are making use of return from machine check \n" + "> >>>> > Some guests are making use of return from machine check =20\n" "> instruction\n" - "> >>>> > to do crazy things even though the 64-bit kernel doesn't \n" + "> >>>> > to do crazy things even though the 64-bit kernel doesn't =20\n" "> handle yet\n" - "> >>>> > this interrupt. Emulate MCSRR0/1 SPR and rfmci instruction \n" + "> >>>> > this interrupt. Emulate MCSRR0/1 SPR and rfmci instruction =20\n" "> accordingly.\n" "> >>>> >\n" "> >>>> > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>\n" "> >>>> > ---\n" "> >>>> > arch/powerpc/include/asm/kvm_host.h | 1 +\n" - "> >>>> > arch/powerpc/kvm/booke_emulate.c | 25 \n" + "> >>>> > arch/powerpc/kvm/booke_emulate.c | 25 =20\n" "> +++++++++++++++++++++++++\n" "> >>>> > arch/powerpc/kvm/timing.c | 1 +\n" "> >>>> > 3 files changed, 27 insertions(+), 0 deletions(-)\n" "> >>>> >\n" - "> >>>> > diff --git a/arch/powerpc/include/asm/kvm_host.h \n" + "> >>>> > diff --git a/arch/powerpc/include/asm/kvm_host.h =20\n" "> b/arch/powerpc/include/asm/kvm_host.h\n" "> >>>> > index af326cd..0466789 100644\n" "> >>>> > --- a/arch/powerpc/include/asm/kvm_host.h\n" @@ -48,46 +48,46 @@ "> >>>> > EMULATED_RFI_EXITS,\n" "> >>>> > EMULATED_RFCI_EXITS,\n" "> >>>> > + EMULATED_RFMCI_EXITS,\n" - "> >>>> I would quite frankly prefer to see us abandon the whole exit \n" - "> timing framework in the kernel and instead use trace points. Then we \n" + "> >>>> I would quite frankly prefer to see us abandon the whole exit =20\n" + "> timing framework in the kernel and instead use trace points. Then we =20\n" "> don't have to maintain all of this randomly exercised code.\n" - "> >>> Would this map well to tracepoints? We're not trying to track \n" + "> >>> Would this map well to tracepoints? We're not trying to track =20\n" "> discrete events, so much as accumulated time spent in different areas.\n" - "> >> I think so. We'd just have to emit tracepoints as soon as we enter \n" - "> handle_exit and in prepare_to_enter. Then a user space program should \n" - "> have everything it needs to create statistics out of that. It would \n" + "> >> I think so. We'd just have to emit tracepoints as soon as we enter =20\n" + "> handle_exit and in prepare_to_enter. Then a user space program should =20\n" + "> have everything it needs to create statistics out of that. It would =20\n" "> certainly simplify the entry/exit path.\n" "> >\n" "> > I was hoping that wasn't going to be your answer. :-)\n" "> >\n" - "> > Such a change would introduce a new dependency, more complexity, \n" - "> and the possibility for bad totals to result from a ring buffer \n" + "> > Such a change would introduce a new dependency, more complexity, =20\n" + "> and the possibility for bad totals to result from a ring buffer =20\n" "> filling faster than userspace can drain it.\n" - "> \n" - "> Well, at least it would allow for optional tracing :). Today you have \n" + ">=20\n" + "> Well, at least it would allow for optional tracing :). Today you have =20\n" "> to change a compile flag to enable / disable timing stats.\n" - "> \n" + ">=20\n" "> >\n" - "> > I also don't see how it would simplify entry/exit, since we'd still \n" - "> need to take timestamps in the same places, in order to record a \n" + "> > I also don't see how it would simplify entry/exit, since we'd still =20\n" + "> need to take timestamps in the same places, in order to record a =20\n" "> final event that says how long a particular event took.\n" - "> \n" - "> Not sure I understand. What the timing stats do is that they measure \n" - "> the time between [exit ... entry], right? We'd do the same thing, \n" - "> 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" + ">=20\n" + "> Not sure I understand. What the timing stats do is that they measure =20\n" + "> the time between [exit ... entry], right? We'd do the same thing, =20\n" + "> 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 just \n" - "a small loss by moving into C code, but a potential for a large loss if \n" - "we overflow the buffer) and a dependency on a userspace tool (both in \n" - "terms of the tool needing to be written, and in the hassle of ensuring \n" - "that it's present in the root filesystem of whatever system I'm \n" + "Compile-time enabling bothers me less than a loss of accuracy (not just =20\n" + "a small loss by moving into C code, but a potential for a large loss if =20\n" + "we overflow the buffer) and a dependency on a userspace tool (both in =20\n" + "terms of the tool needing to be written, and in the hassle of ensuring =20\n" + "that it's present in the root filesystem of whatever system I'm =20\n" "testing). And the whole mechanism will be more complicated.\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" - -Scott + -Scott= -aca353ded0bae55165c99cdab52add7d02fce668a9a36bd3426020dbab37a5a9 +56717828a7ec53e430572769cb1ef1e7a916d6065ec432d4e75c919e69ec7956
diff --git a/a/content_digest b/N2/content_digest index 9cc2e25..abad2e4 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -7,12 +7,12 @@ "ref\0822D94B1-6E7E-4416-9F34-72E3BEAF6B8F@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 21:54:51 +0000\0" + "Date\0Tue, 9 Jul 2013 16:54:51 -0500\0" "To\0Alexander Graf <agraf@suse.de>\0" "Cc\0Mihai Caraman <mihai.caraman@freescale.com>" - kvm-ppc@vger.kernel.org - kvm@vger.kernel.org - " linuxppc-dev@lists.ozlabs.org\0" + <kvm-ppc@vger.kernel.org> + <kvm@vger.kernel.org> + " <linuxppc-dev@lists.ozlabs.org>\0" "\00:1\0" "b\0" "On 07/09/2013 04:49:32 PM, Alexander Graf wrote:\n" @@ -90,4 +90,4 @@ "\n" -Scott -aca353ded0bae55165c99cdab52add7d02fce668a9a36bd3426020dbab37a5a9 +b11718da24adc27b10d9146307228668d723c4a4bb400b1892adec442bf235a2
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.