On Wed, Apr 11, 2012 at 12:35:10PM +0200, Andre Oppermann wrote: > On 11.04.2012 01:32, Luigi Rizzo wrote: > >On Tue, Apr 10, 2012 at 07:05:00PM -0400, Barney Wolff wrote: > >>CPU cache? > >>Cx states? > >>powerd? > > > >powerd is disabled, and i am going down to C1 at most > > > sysctl -a | grep cx > > hw.acpi.cpu.cx_lowest: C1 > > dev.cpu.0.cx_supported: C1/1 C2/80 C3/104 > > > >which shouldn't take so much. Sure, cache matters, but the > >fact is, icmp processing on loopback should occur inline. > > > >unless there is a forced descheduling on a select with timeout> 0 > >which would explain the extra few microseconds (and makes me worry > >on how expensive is a scheduling decision...) > > Things going through loopback go through a NETISR and may > end up queued to avoid LOR situations. In addition per-cpu > queues with hash-distribution for affinity may cause your > packet to be processed by a different core. Hence the additional > delay.
so you suggest that the (de)scheduling is costing several microseconds ? Do we have something like yield() to measure how expensive is the scheduler ? I ran some tests in a distant past and i remember numbers of a few microseconds, but that was almost two gigahertz ago... cheers luigi _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
