> >>However, I *do* agree with you that it's simpler to just squash this patch > >>into 01/11. > >Uh, did I say that? Oh I said why don't make it right the first time! > > > >I meant in terms of seperating the slowpath (aka the bytelock on the pending > >bit) from the queue (MCS code). Or renaming the function to be called > >'complex' instead of 'slowpath' as it is getting quite hairy. > > > >The #1 patch is nice by itself - as it lays out the foundation of the > >MCS-similar code - and if Ingo decides he does not want this pending > >byte-lock bit business - it can be easily reverted or dropped. > > The pending bit code is needed for performance parity with ticket spinlock > for light load. My own measurement indicates that the queuing overhead will > cause the queue spinlock to be slower than ticket spinlock with 2-4 > contending tasks. The pending bit solves the performance problem with 2 Aha! > contending tasks, leave only the 3-4 tasks cases being a bit slower than the > ticket spinlock which should be more than compensated by its superior > performance with heavy contention and slightly better performance with no > contention. That should be mentioned in the commit description as the rationale for the patch "qspinlock: Add pending bit" and also in the code. Thank you! -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
