Messages in this thread | | | Date | Fri, 7 Nov 2008 17:03:07 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH] kprobe: increase kprobe_hash_table size |
| |
On Fri, 07 Nov 2008 19:18:54 -0500 Masami Hiramatsu <mhiramat@redhat.com> wrote:
> Hi Andrew, > > Andrew Morton wrote: > > On Fri, 07 Nov 2008 18:44:30 -0500 Masami Hiramatsu <mhiramat@redhat.com> wrote: > > > >> Increase the size of kprobe hash table to 512. It's useful when hundreds > >> of kprobes were used in the kernel because current size is just 64. > >> > > > > "useful" is a bit vague. How big is the problem which this solves, and > > how well did it solve it? > > For example, when probing enters and exits of syscall-related functions, > we need more than 500 probes. In that case, each hlist would have 8 > elements in average. With this patch, the hlist would have 1 element in > average. > > I agree that there may be many opinions about what is the best suited size. > Why I chose 512 was that I thought the table (byte) size was less than or > equal 4096 even on 64-bit arch.
Well...
text data bss dec hex filename 7036 744 9380 17160 4308 kernel/kprobes.o 7048 744 73892 81684 13f14 kernel/kprobes.o
That's 64 kbytes more memory. It will be kretprobe_table_locks[] which is hurting here, due to the ____cacheline_aligned.
I expected CONFIG_X86_VSMP=y to make this far worse, but fortunately that only affects ____cacheline_internodealigned_in_smp.
btw, that array wastes a ton of memory on uniprocessor builds. Using ____cacheline_aligned_in_smp should fix that.
Please always check these thigns with /usr/bin/size.
btw2, could/should kprobe_table[] and kretprobe_inst_table[] be aggregated into kretprobe_table_locks[]? That would save some memory and might save some cache misses as well?
Anyway, enough pos-facto code review. Is this change which you're proposing worth increasing kernel memory usage by 64k?
| |