On Sun, Apr 21, 2013 at 5:12 PM, Rik van Riel <riel@xxxxxxxxxx> wrote: > Your algorithm is very clever, and very promising. > > However, it does increase the size of the struct spinlock, and adds > an additional atomic operation to spin_unlock, neither of which I > suspect are necessary. > > If we always incremented the ticket number by 2 (instead of 1), then > we could use the lower bit of the ticket number as the spinlock. > > If we do NOT run virtualized, we simply increment the ticket by 2 > in spin_unlock, and the code can remain otherwise the same. > > If we do run virtualized, we take that spinlock after acquiring > the ticket (or timing out), just like in your code. In the > virtualized spin_unlock, we can then release the spinlock and > increment the ticket in one operation: by simply increasing the > ticket by 1. > > In other words, we should be able to keep the overhead of this > to an absolute minimum, and keep spin_unlock to be always the > same cost it is today. > > -- > All rights reversed Hi Rik, Thanks for your feedback. Yes I agree with you - increase the size of struct spinlock is unnecessary - your idea of utilize the lower bit and save one atomic operation from unlock is cool! I can come up with a updated patch soon. --Jiannan -- 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
