> > 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. Ah, I agree. Anyway, the probability of there being too many vmap_blocks being missed due to concurrent changes is not quite high, so I guess its okay that a few vmap_blocks get purged next time. Thanks. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href