On Thu, Oct 20, 2016 at 10:15 PM, Dan Streetman <ddstr...@ieee.org> wrote: > On Wed, Oct 19, 2016 at 12:35 PM, Vitaly Wool <vitalyw...@gmail.com> 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
