On Thu, 8 Dec 2011, Kautuk Consul wrote: > > In the original code, if the if-clause fails, the lock is only then taken > > and the exact same test occurs again while protected. If the test now > > fails, the lock is immediately dropped. A branch here is faster than a > > contented spinlock. > > But, if there is some concurrent change happening to vb->free and > vb->dirty, dont you think > that it will continue and then go to the next vmap_block ? > > If yes, then it will not be put into the purge list. > That's intentional as an optimization, we don't care if vb->free + vb->dirty == VMAP_BBMAP_BITS && vb->dirty != VMAP_BBMAP_BITS would speculatively be true after we grab vb->lock, we'll have to purge it next time instead. We certainly don't want to grab vb->lock for blocks that aren't candidates, so this optimization is a singificant speedup.