diff for duplicates of <1373480698.8183.218@snotra> diff --git a/a/1.txt b/N1/1.txt index 4b75a41..b8366ef 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,71 +1,71 @@ On 07/10/2013 05:23:36 AM, Alexander Graf wrote: -> +>=20 > On 10.07.2013, at 00:26, Scott Wood wrote: -> +>=20 > > On 07/09/2013 05:00:26 PM, Alexander Graf wrote: -> >> 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 +> >> It'll also be more flexible at the same time. You could take the =20 +> logs 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 +> >> 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? -> -> Yeah, first thing I did back then to actually debug kvm failures was +>=20 +> Yeah, first thing I did back then to actually debug kvm failures was =20 > to add trace points. I meant specifically for handling exit timings this way. -> > 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 +> > Is there common infrastructure for dealing with measuring intervals =20 +> and tracking statistics thereof, rather than just tracking points and =20 +> letting userspace connect the dots (though it could still do that as =20 +> an option)? Even if it must be done in userspace, it doesn't seem =20 > like something that should be KVM-specific. -> -> Would you like to have different ways of measuring mm subsystem -> overhead? I don't :). The same goes for KVM really. If we could -> converge towards a single user space interface to get exit timings, +>=20 +> Would you like to have different ways of measuring mm subsystem =20 +> overhead? I don't :). The same goes for KVM really. If we could =20 +> converge towards a single user space interface to get exit timings, =20 > it'd make debugging a lot easier. -I agree -- that's why I said it doesn't seem like something that should -be KVM-specific. But that's orthogonal to whether it's done in kernel -space or user space. The ability to get begin/end events from -userspace would be nice when it is specifically requested, but it would -also be nice if the kernel could track some basic statistics so we +I agree -- that's why I said it doesn't seem like something that should =20 +be KVM-specific. But that's orthogonal to whether it's done in kernel =20 +space or user space. The ability to get begin/end events from =20 +userspace would be nice when it is specifically requested, but it would =20 +also be nice if the kernel could track some basic statistics so we =20 wouldn't have to ship so much data around to arrive at the same result. -At the very least, I'd like such a tool/infrastructure to exist before -we start complaining about doing minor maintenance of the current +At the very least, I'd like such a tool/infrastructure to exist before =20 +we start complaining about doing minor maintenance of the current =20 mechanism. -> We already have this for the debugfs counters btw. And the timing -> framework does break kvm_stat today already, as it emits textual -> stats rather than numbers which all of the other debugfs stats do. -> But at least I can take the x86 kvm_stat tool and run it on ppc just +> We already have this for the debugfs counters btw. And the timing =20 +> framework does break kvm_stat today already, as it emits textual =20 +> stats rather than numbers which all of the other debugfs stats do. =20 +> But at least I can take the x86 kvm_stat tool and run it on ppc just =20 > fine to see exit stats. -We already have what? The last two sentences seem contradictory -- can +We already have what? The last two sentences seem contradictory -- can =20 you or can't you use kvm_stat as is? I'm not familiar with kvm_stat. What does x86 KVM expose in debugfs? -> >> > Lots of debug options are enabled at build time; why must this +> >> > Lots of debug options are enabled at build time; why must this =20 > be 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 +> >> Because I think it's valuable as debug tool for cases where =20 +> compile time switches are not the best way of debugging things. It's =20 +> not a high profile thing to tackle for me tbh, but I don't really =20 +> think working heavily on the timing stat thing is the correct path to =20 > walk along. > > > > Adding new exit types isn't "working heavily" on it. -> -> No, but the fact that the first patch is a fix to add exit stats for -> exits that we missed out before doesn't give me a lot of confidence -> that lots of people use timing stats. And I am always very weary of +>=20 +> No, but the fact that the first patch is a fix to add exit stats for =20 +> exits that we missed out before doesn't give me a lot of confidence =20 +> that lots of people use timing stats. And I am always very weary of =20 > #ifdef'ed code, as it blows up the test matrix heavily. -I used it quite a lot when I was doing KVM performance work. It's just +I used it quite a lot when I was doing KVM performance work. It's just =20 been a while since I last did that. --Scott +-Scott= diff --git a/a/content_digest b/N1/content_digest index b3c4bcd..712633d 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,85 +1,85 @@ "ref\0386A14D3-0968-4FC5-B273-D5D510ADDAF3@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\0Wed, 10 Jul 2013 18:24:58 +0000\0" + "Date\0Wed, 10 Jul 2013 13:24:58 -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/10/2013 05:23:36 AM, Alexander Graf wrote:\n" - "> \n" + ">=20\n" "> On 10.07.2013, at 00:26, Scott Wood wrote:\n" - "> \n" + ">=20\n" "> > On 07/09/2013 05:00:26 PM, Alexander Graf wrote:\n" - "> >> It'll also be more flexible at the same time. You could take the \n" - "> logs and actually check what's going on to debug issues that you're \n" + "> >> It'll also be more flexible at the same time. You could take the =20\n" + "> logs and actually check what's going on to debug issues that you're =20\n" "> encountering for example.\n" - "> >> We could even go as far as sharing the same tool with other \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" - "> Yeah, first thing I did back then to actually debug kvm failures was \n" + ">=20\n" + "> Yeah, first thing I did back then to actually debug kvm failures was =20\n" "> to add trace points.\n" "\n" "I meant specifically for handling exit timings this way.\n" "\n" - "> > Is there common infrastructure for dealing with measuring intervals \n" - "> and tracking statistics thereof, rather than just tracking points and \n" - "> letting userspace connect the dots (though it could still do that as \n" - "> an option)? Even if it must be done in userspace, it doesn't seem \n" + "> > Is there common infrastructure for dealing with measuring intervals =20\n" + "> and tracking statistics thereof, rather than just tracking points and =20\n" + "> letting userspace connect the dots (though it could still do that as =20\n" + "> an option)? Even if it must be done in userspace, it doesn't seem =20\n" "> like something that should be KVM-specific.\n" - "> \n" - "> Would you like to have different ways of measuring mm subsystem \n" - "> overhead? I don't :). The same goes for KVM really. If we could \n" - "> converge towards a single user space interface to get exit timings, \n" + ">=20\n" + "> Would you like to have different ways of measuring mm subsystem =20\n" + "> overhead? I don't :). The same goes for KVM really. If we could =20\n" + "> converge towards a single user space interface to get exit timings, =20\n" "> it'd make debugging a lot easier.\n" "\n" - "I agree -- that's why I said it doesn't seem like something that should \n" - "be KVM-specific. But that's orthogonal to whether it's done in kernel \n" - "space or user space. The ability to get begin/end events from \n" - "userspace would be nice when it is specifically requested, but it would \n" - "also be nice if the kernel could track some basic statistics so we \n" + "I agree -- that's why I said it doesn't seem like something that should =20\n" + "be KVM-specific. But that's orthogonal to whether it's done in kernel =20\n" + "space or user space. The ability to get begin/end events from =20\n" + "userspace would be nice when it is specifically requested, but it would =20\n" + "also be nice if the kernel could track some basic statistics so we =20\n" "wouldn't have to ship so much data around to arrive at the same result.\n" "\n" - "At the very least, I'd like such a tool/infrastructure to exist before \n" - "we start complaining about doing minor maintenance of the current \n" + "At the very least, I'd like such a tool/infrastructure to exist before =20\n" + "we start complaining about doing minor maintenance of the current =20\n" "mechanism.\n" "\n" - "> We already have this for the debugfs counters btw. And the timing \n" - "> framework does break kvm_stat today already, as it emits textual \n" - "> stats rather than numbers which all of the other debugfs stats do. \n" - "> But at least I can take the x86 kvm_stat tool and run it on ppc just \n" + "> We already have this for the debugfs counters btw. And the timing =20\n" + "> framework does break kvm_stat today already, as it emits textual =20\n" + "> stats rather than numbers which all of the other debugfs stats do. =20\n" + "> But at least I can take the x86 kvm_stat tool and run it on ppc just =20\n" "> fine to see exit stats.\n" "\n" - "We already have what? The last two sentences seem contradictory -- can \n" + "We already have what? The last two sentences seem contradictory -- can =20\n" "you or can't you use kvm_stat as is? I'm not familiar with kvm_stat.\n" "\n" "What does x86 KVM expose in debugfs?\n" "\n" - "> >> > Lots of debug options are enabled at build time; why must this \n" + "> >> > Lots of debug options are enabled at build time; why must this =20\n" "> be different?\n" - "> >> Because I think it's valuable as debug tool for cases where \n" - "> compile time switches are not the best way of debugging things. It's \n" - "> not a high profile thing to tackle for me tbh, but I don't really \n" - "> think working heavily on the timing stat thing is the correct path to \n" + "> >> Because I think it's valuable as debug tool for cases where =20\n" + "> compile time switches are not the best way of debugging things. It's =20\n" + "> not a high profile thing to tackle for me tbh, but I don't really =20\n" + "> think working heavily on the timing stat thing is the correct path to =20\n" "> walk along.\n" "> >\n" "> > Adding new exit types isn't \"working heavily\" on it.\n" - "> \n" - "> No, but the fact that the first patch is a fix to add exit stats for \n" - "> exits that we missed out before doesn't give me a lot of confidence \n" - "> that lots of people use timing stats. And I am always very weary of \n" + ">=20\n" + "> No, but the fact that the first patch is a fix to add exit stats for =20\n" + "> exits that we missed out before doesn't give me a lot of confidence =20\n" + "> that lots of people use timing stats. And I am always very weary of =20\n" "> #ifdef'ed code, as it blows up the test matrix heavily.\n" "\n" - "I used it quite a lot when I was doing KVM performance work. It's just \n" + "I used it quite a lot when I was doing KVM performance work. It's just =20\n" "been a while since I last did that.\n" "\n" - -Scott + -Scott= -be574ad027968d4e8529e86adee66fcb31fb1d3bebdc066d7157930796e66ae9 +15f433d5aa716ddd4fc2535ef75cbc9863a097cbc4f838e14b33f0bfab8160fb
diff --git a/a/content_digest b/N2/content_digest index b3c4bcd..d7f8db6 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,12 +1,12 @@ "ref\0386A14D3-0968-4FC5-B273-D5D510ADDAF3@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\0Wed, 10 Jul 2013 18:24:58 +0000\0" + "Date\0Wed, 10 Jul 2013 13:24:58 -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" @@ -82,4 +82,4 @@ "\n" -Scott -be574ad027968d4e8529e86adee66fcb31fb1d3bebdc066d7157930796e66ae9 +9ada3f161b28f35995ed842bd20b8f5885751c032205da81ff10f4b56023ff73
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.