[altq 901] Re: Kernel profiling and ALTQ

[Nicolas Christin <nicolas@cs.virginia.edu>]

Kenjiro Cho wrote:

> You should be aware that kernel profiling is very tricky, especially
> when measuring ALTQ.
> Profiling data is collected at clock interrupts.  When the profiling
> clock is shared with the kernel clock, it cannot correctly gather
> events triggered by clock interrupts.  Also, most of the ALTQ code
> spends time in the interrupt context and/or with interrupt disabled,
> which is another source of synchronization with profiling clock
> interrupts.

	Yes, I can see the problem. But do I have any other choice for 
evaluating the computational complexity of these queuing disciplines?

> > In both cases, I see some entries
> > for if_simloop in the profile, but I don't see functions such as
> > hfsc_enqueue and such. 
>
> if_simloop() is in sys/net/if_loop.c.  It is used to receive packets
> sent to itself (e.g., broadcast packets).

	This makes sense since I was running a test on the loopback 
interface. However, shouldn't I have also seen some calls to 
hfsc_enqueue() and such? Maybe this has to do with the synchronization 
problem you mentioned above (if interrupts the call to hfsc_enqueue() is 
made by a clock interrupt, and if hfsc_enqueue() itself does not allow 
for interrupts, I can see why it doesn't appear in the list). In fact, 
to specify my problem a little bit further, I was wondering if there was 
an actual way of measuring the time spent in hfsc_enqueue() or 
hfsc_dequeue() since these are the functions for which I'm trying to 
assess the computational complexity...

	Thanks for your help,
	--Nick
 
------------------------------------------------------------------------
Nicolas Christin                        nicolas@cs.virginia.edu         
Multimedia Networks Group               http://www.cs.virginia.edu/~nc2y
------------------------------------------------------------------------