----- On Apr 19, 2016, at 3:41 PM, rostedt rostedt@xxxxxxxxxxx wrote: > On Tue, 19 Apr 2016 11:57:32 -0700 > "H. Peter Anvin" <hpa@xxxxxxxxx> wrote: > >> Also, I understand there is one of these bitmaps per ring buffer, and >> the ring buffer is in the tens of megabytes. > > Right, there's only one bitmap per tracing instance, which in most > cases is just one (I know of people who make more). And by default, the > tracing buffer is 1.4 megs per CPU. > > If you have a pid_max of the max size, I highly doubt you will be doing > that on a single CPU machine. If you have 48 CPUs, the ring buffer will > be 1.4 * 48 megs, making the 1/2 meg bitmap a nit. > > I will say, there may be two bitmaps soon, because I plan on adding > this same code to the function tracer logic. Ah indeed, since there is a hard limit to 4194304, that makes the worse case bitmap 512k. We could argue that given a sparse dataset in the PID table (typical in our use-cases), a small hash table would have better cache locality than the bitmap. But I agree that the hash table does add a bit of complexity, so it becomes a complexity vs cache locality tradeoff. So I understand why you would want to go for the simpler bitmap solution, unless the hash table would prove to bring a measurable performance improvement. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|