Messages in this thread | | | Date | Tue, 21 Sep 2010 21:48:58 +0200 | From | Andi Kleen <> | Subject | Re: [PATCH 03/10] jump label v11: base patch |
| |
> I agree with Steven, Peter and Jason: due to the large amount of > tracepoints we can end up patching, we should keep the hash tables. This
I suspect when it's cache cold the hash tables will be actually slower. As a general rule memory bloat = slow.
> code is very similar to what I have in the tracepoints already and in > the immediate values. So this code is solid and has been tested over a > large user base for quite some time already.
FWIW "We always did it this way" is not a good argument in engineering discussions.
> One change I would recommend is to use a separate memory pool to > allocate the struct jump_label_entry, to favor better locality. I did > not do it in tracepoints and markers because each entry have a variable > length, but given that struct jump_label_entry seems to be fixed-size, > then we should definitely go for a kmem_cache_alloc().
Yes even more complexity, great idea.
-Andi -- ak@linux.intel.com -- Speaking for myself only.
| |