Messages in this thread | | | Date | Mon, 22 Sep 2003 12:07:22 +0100 | From | John Levon <> | Subject | Re: [PATCH 2.6.x] additional kernel event notifications |
| |
On Sun, Sep 21, 2003 at 10:59:21PM -0700, Villacis, Juan wrote:
> In some cases, a profiler can figure out information regarding > Dynamically Generate Code (DGC) with help from the generator of the > code, but in other cases it cannot. > > In the case of Java jitted code, our userspace tools obtain sufficient > information through JVMPI, when it is implemented by the JVM.
I would argue that any JVM that doesn't yet implement JVMPI_EVENT_COMPILED_METHOD_LOAD is broken - JVMPI has been around for a long time now.
I don't see why the kernel is the correct place to fix such lacking functionality.
> for DGC which does not have such userspace support, it is important to > be able to spot and accurately attribute samples to DGC. The 4 > additional profiling hooks we proposed can be used for such purposes.
Please be specific about which *actual* cases you're worried about, and why they shouldn't be fixed in userspace.
> If the generator of DGC frees memory used for DGC that subsequently gets > a loaded image (or reuses memory that may have once had an executable > image), you can mis-attribute samples so that instead of attributing the > samples to the DGC, you will attribute the samples to an image. The > dcookie mechanism will indicate information about an image, but doesn't > help prevent mis-attribution of samples if DGC is intermixed with images > that are loaded/unloaded in the same memory region.
Simply flush the sample buffer by echo 1 >/dev/oprofile/dump when you receive a COMPILED_METHOD_LOAD/UNLOAD that conflicts with a previous mapping.
regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |