[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