Messages in this thread | | | Date | Thu, 25 Nov 2010 08:14:46 -0500 | From | Mathieu Desnoyers <> | Subject | Re: [PATCH 1/3] jump label: add enabled/disabled state to jump label key entries |
| |
* Peter Zijlstra (peterz@infradead.org) wrote: [...] > > What would suit us would be to have an arch callback that is called > > after all the transforms for a particular jump label key have been made. > > That way we could optimise the individual patches, and do a sync step at > > the end, ie. when we want the effect of the patching to be globally > > visible. > > I think such a sync-barrier is desired (possibly only on the enable > path) so we can actually say the tracepoints are on. > > Which would mean sending IPIs to all CPUs and waiting for them to > acknowledge them. Which, while not quite as expensive as stop_machine, > its not really cheap either.
Yep, although this can be batched when enabling many tracepoints en masse. May I suggest that you guys benchmark the two approaches so we can figure out at how many tracepoints we start hitting a latency wall ? 100, 1000 and 10000 tracepoints should give interesting measurement points. If we are still below 2 seconds on common hardware when enabling 10000 tracepoints, then the binary search might be fine.
Please note that HPA recommended the use of a perfect hash. It would make sense, although there seems to be a non-null probability that the perfect hash cannot be generated. There are techniques that will retry with a different seed, but the kernel build time then becomes slightly harder to predict (for very, very rare occurences, so maybe we don't care).
Thanks,
Mathieu
-- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com
| |