look, alloc_skb is not inline, so you need to use
__builtin_return_address(0) to know who called alloc_skb, you have to
change struct sk_buff to have an extra member where you will store the
return of __builtin_return_address(0), and possibly another field to store
the jiffies, so that you'll have the time when the alloc_skb was called,
then, later on, you could just printk the time it took from the alloc_skb
to the place where you want to know how long it took to traverse the
section of the network stack you're interested in.
> > About the example of WAITQUEUE_DEBUG:
> >
> > after being awaken you could do this:
>
> > dprintk("sleeper=%p, waker=%lx\n",
> > current_text_addr(), wait.__waker);
>
> > in a inline function does the trick, but this is just an example of a
> > function that uses an extra debug field in a structure that is alocated
> > somewhere and you want to know who allocated it later on.
>
> > Yes, you'll have to decode the address from syslog, gotcha?
> But the __waker member is filled by a macro from wait.h, if I had seen it
> right. Where would you issue such a dprintk call?
> Sorry about my missing knowledge about wait queues, but I don't get the
> point where to fill the member. That I could print it later on, thats
> clear, but how to fill it?
creating another field in the struct sk_buff, like I said above. The whole
point of the wait_queue was to show you the idea, the fact that you could
add another field to the struct you want to watch, see this excerpt from
include/linux/wait.h:
struct __wait_queue {
unsigned int flags;
#define WQ_FLAG_EXCLUSIVE 0x01
struct task_struct * task;
struct list_head task_list;
#if WAITQUEUE_DEBUG
long __magic;
long __waker;
#endif
};
see? you just add a 'long allocator; long jiffies_creation;' to struct
sk_buff like in the struct above, for WAITQUEUE_DEBUG debugging the kernel
has __magic and __waker, and store at alloc_skb time there the return of
__builtin_return_address(0) and jiffies, the later on you use it for your
purposes.
- Arnaldo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/