diff for duplicates of <98992f916f8955717c79dfd8534ebde8@bga.com> diff --git a/a/1.txt b/N1/1.txt index 8086b6b..e989713 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -17,9 +17,9 @@ On Feb 9, 2007, at 1:10 PM, Arnd Bergmann wrote: >>> that can easily recreate the same mapping. >> >> 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. >> @@ -59,19 +59,19 @@ am not proposing this requirement. >>> only performance, right? >> >> 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 @@ -97,7 +97,7 @@ entry if all hased to the same vm area. >>> This seems to incur a run-time overhead on the SPU even if not >>> profiling, I would consider that not acceptable. >> ->> 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 diff --git a/a/content_digest b/N1/content_digest index 66bbe64..b8233e8 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -6,11 +6,11 @@ "Subject\0Re: [Cbe-oss-dev] [RFC, PATCH] CELL Oprofile SPU profiling updated patch\0" "Date\0Fri, 9 Feb 2007 13:46:50 -0600\0" "To\0Arnd Bergmann <arnd@arndb.de>\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" "\n" @@ -32,9 +32,9 @@ ">>> that can easily recreate the same mapping.\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" ">>\n" @@ -74,19 +74,19 @@ ">>> only performance, right?\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" @@ -112,7 +112,7 @@ ">>> This seems to incur a run-time overhead on the SPU even if not\n" ">>> profiling, I would consider that not acceptable.\n" ">>\n" - ">> It definitely is overhead. =A0Which means it would have to be\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" @@ -124,4 +124,4 @@ "\n" milton -9fc0930919d06c16a5eaae3c288e1d671f79f2111f83f35e8f28e2e049056672 +425567943c9fd4a69eb6ce3fc3c83041001b42384bd9d8ef60e675a134ced461
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.