> On Jan 23, 2020, at 3:39 PM, Waiman Long <longman@xxxxxxxxxx> wrote: > > On 1/23/20 2:55 PM, Waiman Long wrote: >> Playing with lock event counts, I would like you to change the meaning >> intra_count parameter that you are tracking. Instead of tracking the >> number of times a lock is passed to a waiter of the same node >> consecutively, I would like you to track the number of times the head >> waiter in the secondary queue has given up its chance to acquire the >> lock because a later waiter has jumped the queue and acquire the lock >> before it. Isn’t that the same thing? Note that we keep track of the number of intra-node lock transfers only when the secondary queue is not empty. >> This value determines the worst case latency that a secondary >> queue waiter can experience. So > > Well, that is not strictly true as a a waiter in the middle of the > secondary queue can go back and fro between the queues for a number of > times. Of course, if we can ensure that when a FLUSH_SECONDARY_QUEUE is > issued, those waiters that were in the secondary queue won't be put back > into the secondary queue again. This will not work as intended when we have more than 2 nodes. That is, if we have threads from node A & B in the secondary queue, and then the queue is flushed and its head (say, from node A) gets the lock, we want to push threads from node B back into the secondary queue, to keep the lock on node A. And if we have only 2 nodes, a waiter in the middle of the secondary queue will never go back into the secondary queue, even if the threshold is small. This is because we flush the secondary queue by putting all its waiters in the front of the main queue, and the secondary queue will remain empty at least until we reach a thread from another node. Regards, — Alex
