On Thu, May 10, 2007 at 03:39:36PM -0400, Mathieu Desnoyers wrote: > * Christoph Hellwig ([EMAIL PROTECTED]) wrote: > > On Thu, May 03, 2007 at 01:16:46PM -0400, Mathieu Desnoyers wrote: > > > > kprobes does this kind of synchronization internally, so the marker > > > > wrapper should probabl aswell. > > > > > > > > > > The problem appears on heavily loaded systems. Doing 50 > > > synchronize_sched() calls in a row can take up to a few seconds on a > > > 4-way machine. This is why I prefer to do it in the module to which > > > the callbacks belong. > > > > We recently had a discussion on batch unreistration interface for > > kprobes. I'm not very happy with having so different interfaces for > > different kind of probe registrations. > > > > Ok, I've had a look at the kprobes batch registration mechanisms and.. > well, it does not look well suited for the markers. Adding > supplementary data structures such as linked lists of probes does not > look like a good match. > > However, I agree with you that providing a similar API is good. > > Therefore, here is my proposal : > > The goal is to do the synchronize just after we unregister the last > probe handler provided by a given module. Since the unregistration > functions iterate on every marker present in the kernel, we can keep a > count of how many probes provided by the same module are still present. > If we see that we unregistered the last probe pointing to this module, > we issue a synchronize_sched(). > > It adds no data structure and keeps the same order of complexity as what > is already there, we only have to do 2 passes in the marker structures : > the first one finds the module associated with the callback and the > second disables the callbacks and keep a count of the number of > callbacks associated with the module. > > Mathieu > > P.S.: here is the code. > > > Linux Kernel Markers - Architecture Independant code Provide internal > synchronize_sched() in batch. > > The goal is to do the synchronize just after we unregister the last > probe handler provided by a given module. Since the unregistration > functions iterate on every marker present in the kernel, we can keep a > count of how many probes provided by the same module are still present. > If we see that we unregistered the last probe pointing to this module, > we issue a synchronize_sched(). > > It adds no data structure and keeps the same order of complexity as what > is already there, we only have to do 2 passes in the marker structures : > the first one finds the module associated with the callback and the > second disables the callbacks and keep a count of the number of > callbacks associated with the module.
Looks good to me, please incorporate this is the next round of the markers patch series. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
