On Thu, Aug 13, 2015 at 8:26 AM, Ilya Maximets
wrote:
> Ok, thanks for explanation.
> In that case, I think, try-lock solution will be good.
>
> Best regards, Ilya Maximets.
>
Thx Ilya, for the suggestions and discussion
I posted a patch here:
http://openvswitch.org/pipermail/dev/2015-August/
Ok, thanks for explanation.
In that case, I think, try-lock solution will be good.
Best regards, Ilya Maximets.
On 12.08.2015 23:52, Alex Wang wrote:
> Hey Ilya,
>
> Thanks for the reply please see my comments inline,
>
> Thanks,
> Alex Wang,
>
> On Wed, Aug 12, 2015 at 4:19 AM, Ilya Maximets
Hey Ilya,
Thanks for the reply please see my comments inline,
Thanks,
Alex Wang,
On Wed, Aug 12, 2015 at 4:19 AM, Ilya Maximets
wrote:
> I agree, that this solution is much more simple, but I don't like this
> race for
> coverage_mutex.
> Why this all done so?
>
Before implementing pmd thread
I agree, that this solution is much more simple, but I don't like this race for
coverage_mutex.
Why this all done so?
I mean, why we should run coverage_clear every second? What if we change type of
thread_local unsigned int counter_##COUNTER from unsigned int to unsigned long
long
and will call
Just trying share an alternative, could we still do the coverage clear
inside 'pmd_thread_main()'. However,
instead of contending for the 'coverage_mutex', use 'ovs_mutex_trylock()'.
Since pmd thread runs in infinite
loop, it can constantly try grabbing the lock and will eventually acquire
it.
So
Hi IIya,
Thx a lot for writing up this fix,
The reason that you did not see the pmd related coverage counter stats
(in "ovs-appctl coverage/show") is that we do not call coverage_clear()
anywhere in pmd_thread_main(). This is in that the coverage_clear()
requires holding the global mutex in the
Currently coverage_counter_register() is called only from
constructor functions at program initialization time by
main thread. Coverage counter values are static and
thread local.
This means, that all COVERAGE_INC() calls from pmd threads
leads to increment of thread local variables of that thread
