On 11.04.2012 13:00, Luigi Rizzo wrote: > 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 ? Not directly. I'm just trying to explain what's going on to get a better idea where it may go wrong. There may be a poor ISR/scheduler interaction that prevents that causes the packet to be processed only on the next tick or something like that. I don't have a better explanation for this. > 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... -- AndreReceived on Wed Apr 11 2012 - 10:16:10 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:25 UTC