Re: [Bug kprobes/2062] Return probes does not scale well on SMP box

["James Dickens" <jamesd dot wi at gmail dot com>]

[snipped]
> It is not a big deal, but some people might object that kprobes is touching
> core kernel data structure like task struct. Not sure about the penalty of
> this extra space in task struct. We need to submit a patch and see what
> community has to say.
>
perhaps it would be best to implement a new api that can be extended
add one pointer (to a linked list) to the task struct that many
projects can use as needed, so its just not for systemtap but any
futrue project can use it as well. this may be an easier pill for the
kernel guys to swallow knowing they won't have to have these special
requests comming in over time.

struct task_extensions
     int   signature;  /* each project would pick a signature to
locate its pointer in the future */
     sturct * private_project_data
     struct  *next_task_extension

> But do you also envision a per-task pool of kretprobe_instances?  If so, how
> > big?  If not, aren't we back to locking some sort of free list, at least for
> the
> > sleeping and/or recursive functions?

there are  32 cocurrent thread machines availible today.. in less than
2 year dual  64 concurrent thread (128 thread) boxes will be availible
on the market place you don't want to redesign this thing in 4 years
do you?

>
> Having to allocate per-task pool would be very expensive, as every task that
> gets created will have to allocat the memory and release it when the task is
> dead no matter the retprobe gets fired or not.

using the above mentioned shared private task struct you can recycle
as tasks are retired.  we could even use kprobes to catch task
creation and destroys to create the task structs.



>
> I guess at the first step, it should be okay to have the lock in the kretprobe
> prepare stage(since other than moving the kretprobe instance from free list to
> used list, we don;t do much holding the lock)
>
> > I suppose we could avoid preallocating the kretprobe instances at all, and
> just
> > allocate them as needed from GFP_ATOMIC space. :-}
> This could be other alternative, we can try this one too.
>
>
> -Anil
>
>
> --
>
>
> http://sourceware.org/bugzilla/show_bug.cgi?id=2062
>
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
>