[Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests).

rrs (Randall Stewart) phabric-noreply at FreeBSD.org
Wed Feb 18 11:38:00 UTC 2015


rrs added a comment.

I have thought long and hard about this. I don't think its a bug.
But to know for sure I will need to add some instrumentation.

I suspect what is happening is a tremendous number of callouts
all come due at the same time. The three back traces trying to stop or reset
a callout are just unlucky in they don't get the lock as the callout code
works through doing its loops of
 CC_LOCK(cc)
 while there is more on the list
   prepare callout
   CC_UNLOCK(cc)
    call_callout_function
   CC_LOCK(cc)
 done
CC_UNLOCK(cc)

The spin-mtx has (from what I can see) no awareness of the fact that you might
have lost several bids to get the lock. It just crashes if it spins for too long
and cannot get the lock.

The previous problem is fixed, which I could reproduce, where the callout temp-list
was corrupt and pointing to itself.. thus the soft clock looped forever...

Hiren/Sbruno:

Let me make a special patch that includes some counts in the cpu_cc structure
that we can find out
1) For both callout loops how many the last call had
2) For both callout loops what was the max ever seen

This will give us a hint if I am correct.

I have also asked jhb on his thoughts for this in email.

R

REVISION DETAIL
  https://reviews.freebsd.org/D1711

To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, sbruno, imp, adrian, hselasky
Cc: julian, hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net


More information about the freebsd-net mailing list