[ovs-discuss] cycles_count_xxx CPU overhead

nickcooper-zhangtonghao nic at opencloud.tech
Mon Jan 16 12:49:48 UTC 2017


Thanks very much. Got it.

Thanks.
Nick

> On Jan 16, 2017, at 12:31 PM, Daniele Di Proietto <diproiettod at ovn.org> wrote:
> 
> 2017-01-12 23:47 GMT-08:00 nickcooper-zhangtonghao <nic at opencloud.tech <mailto:nic at opencloud.tech>>:
>> The dp_netdev_process_rxq_port() will use the “cycles_count_start” and
>> “cycles_count_end” for counting the cycles.
>> But via perf tool, I found that cycles_count_xxx uses a lot of CPU. One
>> question to ask: there is one thread to use the
>> pmd struct to processing the packets, right? If so, pmd should be thread
>> safety and atomic should not be used for
>> cycles_count_xxx.
> 
> 'pmd->cycles' is also read by the main thread.
> 
> The idea is that we don't care about being too accurate, but we
> shouldn't be totally inconsistent.
> 
> As explained in 'non_atomic_ullong_add()', we're not doing atomic
> increments.  We're also not using any memory barrier ('relaxed').
> 
> By using atomic operation we're only asking the compiler to read/write
> the 64-bit word in a single operation, to prevent reading the most
> significant 32-bits from an old version and the least significant from
> a new version.
> 
> This should have no impact on 64-bit architectures (the generated asm
> should be the same as the non atomic case), but might have an effect
> on 32-bit architectures.
> 
> I suspect that the functions might show up in perf only when the
> thread is not processing packets, because we're executing very few
> lines of code over and over.
> 
> Does this make sense to you?
> 
> Thanks,
> 
> Daniele

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20170116/90a07946/attachment.html>


More information about the discuss mailing list