Re: Default number of active kretprobes

[Jim Keniston <jkenisto at us dot ibm dot com>]

On Thu, 2006-03-23 at 07:07, William Cohen wrote:
> Martin noticed that some of the examples were dropping kretprobes on
> his laptop running a uniprocessor kernel. It appears the maximum
> number of return events allowed at a time is too small. Example works
> on smp kernel, but run out of return probes on uniprocessor
> kernels. Did some investigation earlier this week. The struct
> kretprobe has maxactive field to track number of entries available.
> 
...
> 
> kprobe register_kretprobe() has the following questionable code. Why
> handle preemptable kernels specially? Why not just have max(10, 2 
> *NR_CPUS) in all cases?

Kprobes is working as documented in Documentation/kprobes.txt.

If the function isn't recursive and doesn't yield the CPU (which is the
case for lots of kernel functions), then there should never be more than
NR_CPUS instances active.

But if preemption is enabled, the chances of the function yielding the
CPU (involuntarily) are greater, so we bump up maxactive (somewhat
arbitrarily).

The intention was that the user will specify a bigger (or smaller) value
for maxactive if the default is not appropriate.  This is perhaps
inconvenient for SystemTap, which wants to do everything possible for
the user.  SystemTap could choose a larger "default" and/or allow the
user to explicitly specify a value for maxactive.  This is the subject
of bugzilla #1802.

Jim

> 
> #ifdef CONFIG_PREEMPT
>                  rp->maxactive = max(10, 2 * NR_CPUS);
> #else
>                  rp->maxactive = NR_CPUS;
> #endif
> 
> in include/linux/threads.h
> 
> #ifdef CONFIG_SMP
> #define NR_CPUS         CONFIG_NR_CPUS
> #else
> #define NR_CPUS         1
> #endif
> 
> CONFIG_NR_CPUS
> 
> ./arch/i386/defconfig:CONFIG_NR_CPUS=8