On Tue, 19 Apr 2016 20:17:29 +0000 (UTC) Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote: > Ah indeed, since there is a hard limit to 4194304, that makes the > worse case bitmap 512k. Yep. > > 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. We discussed this too (cache locality), and came to the same conclusion that a bitmask would still be better. If you think about it, if you have a lot of CPUs and lots of PIDs, tasks don't migrate as much, and if they do, cache locality of this bitmap will be the least of the performance issues. Then you have a limited amount of PIDs per CPU, and thus those PIDs will probably be in the CPU cache for the bitmap. Note, that the check of the bitmap to trace a task or not is not done at every tracepoint. It's only done at sched_switch, and then an internal flag is set. That flag will determine if the event should be traced, and that is a single bit checked all the time (very good for cache). -- Steve -- 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
|