diff for duplicates of <200702092010.27162.arnd@arndb.de> diff --git a/a/1.txt b/N1/1.txt index a0e2771..8caffa7 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,6 +1,6 @@ On Friday 09 February 2007 19:47, Milton Miller wrote: > On Feb 8, 2007, at 11:21 AM, Arnd Bergmann wrote: ->=20 +> > > Doing the translation in two stages in user space, as you > > suggest here, definitely makes sense to me. I think it @@ -12,14 +12,14 @@ On Friday 09 February 2007 19:47, Milton Miller wrote: > > came up with. If the kernel only gives the dcookie information > > about the SPU ELF binary to the oprofile user space, then > > that can easily recreate the same mapping. ->=20 +> > Actually, I was trying to cover issues such as anonymous -> memory. =A0 If the kernel doesn't generate dcookies for +> memory. If the kernel doesn't generate dcookies for > the load segments the information is not recoverable once -> the task exits. =A0This would also allow the loader to create +> the task exits. This would also allow the loader to create > an artifical elf header that covered both the base executable > and a dynamicly linked one. ->=20 +> > Other alternatives exist, such as a structure for context-id > that would have its own identifing magic and an array of elf > header pointers. @@ -30,31 +30,31 @@ would want to create artificial elf headers... > > The kernel still needs to provide the overlay identifiers > > though. ->=20 +> > Yes, which means it needs to parse the header (or libpse > be enhanced to write the monitor info to a spufs file). we thought about this in the past and discarded it because of the complexity of an spufs interface that would handle this -correctly.=20 +correctly. > > yes, this sounds nice. But tt does not at all help accuracy, > > only performance, right? ->=20 +> > It allows the user space to know when the sample was taken -> and =A0be aware of the ambiguity. =A0 If the sample rate is +> and be aware of the ambiguity. If the sample rate is > high enough in relation to the overlay switch rate, user space > could decide to discard the ambiguous samples. yes, good point. -> >> This approach allows multiple objects by its nature. =A0A new +> >> This approach allows multiple objects by its nature. A new > >> elf header could be constructed in memory that contained > >> the union of the elf objects load segments, and the tools -> >> will magically work. =A0 Alternatively the object id could +> >> will magically work. Alternatively the object id could > >> point to a new structure, identified via a new header, that > >> it points to other elf headers (easily differentiated by the -> >> elf magic headers). =A0 Other binary formats, including several +> >> elf magic headers). Other binary formats, including several > >> objects in a ar archive, could be supported. > > > > Yes, that would be a new feature if the kernel passed dcookie @@ -64,7 +64,7 @@ yes, good point. > > on the SPU is currently lacking the relocation mechanisms > > that you would need for resolving spu-side symbols at load > > time ->=20 +> > Actually, It could check all load segments, and only report > those where the dcookie changes (as opposed to the offset). @@ -73,13 +73,13 @@ my point as well. > > This seems to incur a run-time overhead on the SPU even if not > > profiling, I would consider that not acceptable. ->=20 -> It definitely is overhead. =A0Which means it would have to be +> +> It definitely is overhead. Which means it would have to be > optional, like gprof. There is some work going on for another profiler independent of the hardware feature that only relies on instrumenting the spu executable for things like DMA transfers and overlay -changes.=20 +changes. Arnd <>< diff --git a/a/content_digest b/N1/content_digest index 48629dc..2fdf63e 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -5,16 +5,16 @@ "Subject\0Re: [Cbe-oss-dev] [RFC, PATCH] CELL Oprofile SPU profiling updated patch\0" "Date\0Fri, 9 Feb 2007 20:10:26 +0100\0" "To\0Milton Miller <miltonm@bga.com>\0" - "Cc\0linuxppc-dev@ozlabs.org" + "Cc\0cbe-oss-dev@ozlabs.org" + LKML <linux-kernel@vger.kernel.org> + linuxppc-dev@ozlabs.org Carl Love <cel@us.ibm.com> - cbe-oss-dev@ozlabs.org - oprofile-list@lists.sourceforge.net - " LKML <linux-kernel@vger.kernel.org>\0" + " oprofile-list@lists.sourceforge.net\0" "\00:1\0" "b\0" "On Friday 09 February 2007 19:47, Milton Miller wrote:\n" "> On Feb 8, 2007, at 11:21 AM, Arnd Bergmann wrote:\n" - ">=20\n" + "> \n" "\n" "> > Doing the translation in two stages in user space, as you\n" "> > suggest here, definitely makes sense to me. I think it\n" @@ -26,14 +26,14 @@ "> > came up with. If the kernel only gives the dcookie information\n" "> > about the SPU ELF binary to the oprofile user space, then\n" "> > that can easily recreate the same mapping.\n" - ">=20\n" + "> \n" "> Actually, I was trying to cover issues such as anonymous\n" - "> memory. =A0 If the kernel doesn't generate dcookies for\n" + "> memory. \302\240 If the kernel doesn't generate dcookies for\n" "> the load segments the information is not recoverable once\n" - "> the task exits. =A0This would also allow the loader to create\n" + "> the task exits. \302\240This would also allow the loader to create\n" "> an artifical elf header that covered both the base executable\n" "> and a dynamicly linked one.\n" - ">=20\n" + "> \n" "> Other alternatives exist, such as a structure for context-id\n" "> that would have its own identifing magic and an array of elf\n" "> header pointers.\n" @@ -44,31 +44,31 @@ "\n" "> > The kernel still needs to provide the overlay identifiers\n" "> > though.\n" - ">=20\n" + "> \n" "> Yes, which means it needs to parse the header (or libpse\n" "> be enhanced to write the monitor info to a spufs file).\n" "\n" "we thought about this in the past and discarded it because of\n" "the complexity of an spufs interface that would handle this\n" - "correctly.=20\n" + "correctly. \n" "\n" "> > yes, this sounds nice. But tt does not at all help accuracy,\n" "> > only performance, right?\n" - ">=20\n" + "> \n" "> It allows the user space to know when the sample was taken\n" - "> and =A0be aware of the ambiguity. =A0 If the sample rate is\n" + "> and \302\240be aware of the ambiguity. \302\240 If the sample rate is\n" "> high enough in relation to the overlay switch rate, user space\n" "> could decide to discard the ambiguous samples.\n" "\n" "yes, good point.\n" "\n" - "> >> This approach allows multiple objects by its nature. =A0A new\n" + "> >> This approach allows multiple objects by its nature. \302\240A new\n" "> >> elf header could be constructed in memory that contained\n" "> >> the union of the elf objects load segments, and the tools\n" - "> >> will magically work. =A0 Alternatively the object id could\n" + "> >> will magically work. \302\240 Alternatively the object id could\n" "> >> point to a new structure, identified via a new header, that\n" "> >> it points to other elf headers (easily differentiated by the\n" - "> >> elf magic headers). =A0 Other binary formats, including several\n" + "> >> elf magic headers). \302\240 Other binary formats, including several\n" "> >> objects in a ar archive, could be supported.\n" "> >\n" "> > Yes, that would be a new feature if the kernel passed dcookie\n" @@ -78,7 +78,7 @@ "> > on the SPU is currently lacking the relocation mechanisms\n" "> > that you would need for resolving spu-side symbols at load\n" "> > time\n" - ">=20\n" + "> \n" "> Actually, It could check all load segments, and only report\n" "> those where the dcookie changes (as opposed to the offset).\n" "\n" @@ -87,15 +87,15 @@ "\n" "> > This seems to incur a run-time overhead on the SPU even if not\n" "> > profiling, I would consider that not acceptable.\n" - ">=20\n" - "> It definitely is overhead. =A0Which means it would have to be\n" + "> \n" + "> It definitely is overhead. \302\240Which means it would have to be\n" "> optional, like gprof.\n" "\n" "There is some work going on for another profiler independent\n" "of the hardware feature that only relies on instrumenting the\n" "spu executable for things like DMA transfers and overlay\n" - "changes.=20\n" + "changes. \n" "\n" "\tArnd <><" -30ec0287cb7bef6921de34548f53fbb599741554fcc06440cc425b3f88d1ef22 +01ebc9ecd8763be3b86afbd291b319c33c915fdd798c7efc8c09807c2f118de6
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.