From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755131AbcISJ7b (ORCPT ); Mon, 19 Sep 2016 05:59:31 -0400 Received: from mx2.suse.de ([195.135.220.15]:49827 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752821AbcISJ7U (ORCPT ); Mon, 19 Sep 2016 05:59:20 -0400 Date: Mon, 19 Sep 2016 11:59:14 +0200 From: Jan Kara To: "Dilger, Andreas" Cc: Greg Kroah-Hartman , Jan Kara , James Simmons , "devel@driverdev.osuosl.org" , Linux Kernel Mailing List , "Drokin, Oleg" , Lustre Development List , "linux-fsdevel@vger.kernel.org" , "linux-ext4@vger.kernel.org" , dbueso@suse.com Subject: Re: [lustre-devel] [PATCH 030/124] staging: lustre: llite: Replace write mutex with range lock Message-ID: <20160919095914.GH11487@quack2.suse.cz> References: <1474231143-4061-1-git-send-email-jsimmons@infradead.org> <1474231143-4061-31-git-send-email-jsimmons@infradead.org> <20160919072859.GA15407@kroah.com> <5FCA4C55-DF73-4AE8-8030-9A85B21A8A54@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5FCA4C55-DF73-4AE8-8030-9A85B21A8A54@intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 19-09-16 09:25:48, Dilger, Andreas wrote: > On Sep 19, 2016, at 09:28, Greg Kroah-Hartman wrote: > > > > On Sun, Sep 18, 2016 at 04:37:29PM -0400, James Simmons wrote: > >> + * Range lock is used to allow multiple threads writing a single shared > >> + * file given each thread is writing to a non-overlapping portion of the > >> + * file. > >> + * > >> + * Refer to the possible upstream kernel version of range lock by > >> + * Jan Kara : https://lkml.org/lkml/2013/1/31/480 > >> + * > >> + * This file could later replaced by the upstream kernel version. > > > > It doesn't look like range_lock ever got accepted in the kernel tree, > > any idea what happened to it? Having a per-filesystem lock type seems > > odd to me... > > I've added Jan and linux-fsdevel to the CC list to see what interest > there is in the range locking implementaion. At the time we added this > to Lustre it appeared that this was moving nicely torward landing, but > it seems to have stalled. > > I think the range locking implementation is fairly generic, and if there > are other users in the kernel it could easily be pulled out of the staging > dir into vfs/. I'm not against it going into vfs/ directly either, but > not sure whether that is acceptable if the only user is in staging. Yeah, so the problem with my range_lock implementation (and your one looks fairly similar from a quick look) is that it is fairly heavyweight. That may be OK for an inode_lock replacement but it needs a careful benchmarking. Davidlohr was looking into making the implementation more efficient (he wanted to use it for mmap_sem) but I think it got preempted by other work. Honza -- Jan Kara SUSE Labs, CR