From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752819AbcKHPIH (ORCPT ); Tue, 8 Nov 2016 10:08:07 -0500 Received: from one.firstfloor.org ([193.170.194.197]:32977 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751455AbcKHPID (ORCPT ); Tue, 8 Nov 2016 10:08:03 -0500 Date: Tue, 8 Nov 2016 07:08:00 -0800 From: Andi Kleen To: Vitaly Wool Cc: Linux-MM , linux-kernel@vger.kernel.org, Dan Streetman , Andrew Morton , Andi Kleen Subject: Re: [PATCH/RFC v2] z3fold: use per-page read/write lock Message-ID: <20161108150800.GL26852@two.firstfloor.org> References: <20161108135834.d0b57fa435393c64f358980a@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161108135834.d0b57fa435393c64f358980a@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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