On Tue, Nov 08, 2016 at 01:58:34PM +0100, Vitaly Wool wrote: > Most of z3fold operations are in-page, such as modifying z3fold > page header or moving z3fold objects within a page. Taking > per-pool spinlock to protect per-page objects is therefore > suboptimal, and the idea of having a per-page spinlock (or rwlock) > has been around for some time. However, adding one directly to the > z3fold header makes the latter quite big on some systems so that > it won't fit in a signle chunk. > > This patch implements spinlock-based per-page locking mechanism > which is lightweight enough to fit into the z3fold header. > > Changes from v1 [1]: > - custom locking mechanism changed to spinlocks > - no read/write locks, just per-page spinlock Looks good. BTW the spinlock could still grow when debug options like lockdep are enabled. So something would still need to be done about that BUILD_BUG_ON(). Otherwise would need to force a raw spin lock. -Andi -- 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>