On Thu, Oct 20, 2016 at 10:15 PM, Dan Streetman <ddstreet@xxxxxxxx> wrote: > On Wed, Oct 19, 2016 at 12:35 PM, Vitaly Wool <vitalywool@xxxxxxxxx> wrote: >> The per-pool z3fold spinlock should generally be taken only when >> a non-atomic pool variable is modified. There's no need to take it >> to map/unmap an object. This patch introduces per-page lock that >> will be used instead to protect per-page variables in map/unmap >> functions. > > I think the per-page lock must be held around almost all access to any > page zhdr data; previously that was protected by the pool lock. Right, except for list operations. At this point I think per-page locks will have to be thought over again, and there is some nice performance gain from making spinlock a rwlock anyway, so I'll stick with the latest patchset, fixing tiny bits like wrong unbuddied_nr increment in the other patch. Best regards, Vitaly -- 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/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>