Messages in this thread | | | Date | Sat, 26 Apr 2014 09:12:14 +0200 | From | Ingo Molnar <> | Subject | Re: Re: [PATCH -tip v9 25/26] kprobes: Introduce kprobe cache to reduce cache misshits |
| |
* Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> wrote:
> (2014/04/25 17:20), Ingo Molnar wrote: > > > > * Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> wrote: > > > >>> So I don't think this should be a Kconfig entry, just enable it > >>> unconditionally. That will further simplify the code. > >> > >> Hmm, it consumes some amount of memory (36KB/core) just for the > >> case of several thousand of kprobes. On enterprise servers and > >> desktop it's OK, no problem. But I think, some embedded systems > >> with small resources will not want that. [...] > > > > They'll just disable kprobes in general. > > No, I'd like to provide kprobes (and dynamic events) to them > (including me) for debugging and dynamic monitoring, instead of > modifying code for adding events on their kernel. To solve some > specific issues, specific events (not generic events) are required. > Making local patches to add such events is an option, but it > increases maintenance cost for rebasing. It is better to pay cost to > maintain this kconfig on upstream as the maintainer for me instead > of paying such ugly local cost. :( > > Anyway, this option is not easy for beginners, I think it should be > defined with "if EXPERT" option and make it enabled by default. > > > Really, at this point complexity is our main concern. > > Agreed about complexity issue. However, even if we remove the > Kconfig, we can just save 6 lines of the code, and one #ifdef block. > Can that really solve the complexity problem?
It's more about the mental picture about how kprobes works. The fewer binary state flags, the better.
Thanks,
Ingo
| |