On Tue, 2013-06-11 at 13:32 -0700, Paul E. McKenney wrote: > /* > * This lock has lots of spinners, but no queue. Go create > * a queue to spin on. > * > * In the common case, only the single task that > * sees the head and tail tickets being different by > * exactly TKT_Q_SWITCH will come here set up the queue, > * which prevents a "thundering herd" of queue setups. > * Although it is still possible for an unfortunate series > * of lock handoffs and newly arrived tasks to result > * in more than one task performing a queue setup, this > * is unlikely. Of course, this situation must still be > * handled correctly, which is the job of the cmpxchg() > * in tkt_q_start_contend(). > */ > if (tkt_q_start_contend(ap, inc)) > return true; > > Does that help?
Yes, very good. > > > As TKT_Q_SWITCH doesn't have a type, I'm not sure how C will evaluate > > this. I always screw type conversions up, and just add in the type casts > > to be safe. > > > > You could also give TKT_Q_SWITCH a type too. > > This is an excellent point as well -- things might well get confused. > My solution was to take your last suggestion and given TKT_Q_SWITCH the > same type as inc.tail and inc.head, and also apply type-safety paranoia > to TKT_Q_NQUEUES: > > /* > * TKT_Q_SWITCH is twice the number of CPUs that must be spinning on a > * given ticket lock to motivate switching to spinning on a queue. > * The reason that it is twice the number is because the bottom bit of > * the ticket is reserved for the bit that indicates that a queue is > * associated with the lock. > */ > #define TKT_Q_SWITCH ((__ticket_t)(CONFIG_TICKET_LOCK_QUEUED_SWITCH * 2)) > > /* > * TKT_Q_NQUEUES is the number of queues to maintain. Large systems > * might have multiple highly contended locks, so provide more queues for > * systems with larger numbers of CPUs. > */ > #define TKT_Q_NQUEUES (2 * DIV_ROUND_UP(NR_CPUS + ((int)TKT_Q_SWITCH) - 1, \ > (int)TKT_Q_SWITCH)) > > Does that look OK? (The limits on the value of TKT_Q_SWITCH should avoid > signed integer overflow.) > Looks fine. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
