Received: by 10.223.164.202 with SMTP id h10csp2620931wrb; Mon, 27 Nov 2017 21:27:35 -0800 (PST) X-Google-Smtp-Source: AGs4zMazgRd3wWyz0IOAw6aMUwexlw7tBUA6s6RA0ZiA5Wo9gj0pTaV4IKL+sQPR563I6PEQ8GWr X-Received: by 10.98.252.7 with SMTP id e7mr39371128pfh.12.1511846855823; Mon, 27 Nov 2017 21:27:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511846855; cv=none; d=google.com; s=arc-20160816; b=zWFF2gXmMCaCPDCGnBA5dJ16utyRkbawwTjhb+k0XrcaszeM/1mTkiPwfE75m82I3a 0TsXwSj0ncdabEwLw6dsq99/FP1OYLjpzXd5zFer/jCOStdy+H7nf79wmdZhi+jg3LRY LIjfF3lesknwEj/XbikW2khtCkjPN4OOKbx0QTKQdl8afmOsWObGmqiV+Tgy8zAiKYz0 hFnZ5lj4rvpa8oQ4zkTEotc9+dFbGMjcqxzShpgJ6B6XyJWRmqQPTDemDxOt/uUNGFy/ 8SDPGF2gl7hHcOhe3CqtqtwnumV+QxMCt6E/rgR9tQ1WecGS/mVgfMBwaONJKpUyNzbA 36yg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-disposition :content-transfer-encoding:mime-version:in-reply-to:references :subject:cc:to:from:date:message-id:arc-authentication-results; bh=ME/ngD+MdSULPcqg5Pq0JdRUNJ2GTZ2Z2YX6H2SSDBc=; b=0dcKqRwVfoyHBRd1OJYWlFCsCy/U8n8/9mwYIKxWEdmLOy4Rh0o4qp8TFkgz8ILc/w ycZU10DeEIBIrNLsSPvVG3dQ7gHeL+V+KeFPLNKAVA+KfiZye7Dx/bBjuaE1qzlsPSy+ h17SC/bcLByTJS6OM+JVBWSlMKe4bMj09U3UNKKK668oNYAtXEzH6F93a1BsfeABx+LU eoLfGn+a7hTUrwROLOSY6UYvUQLeRXxMqj/C+fWIAnx/EvrKk5LE1QQ3OAVqH3fL90m4 OQ3kyqjTnsqN2vzCAmJAZwLLz6zF2FkxvNBhcQLhrgPSwwlxJZbgTZX0S/80Nh8VUUIr aJDg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q13si23769298pgp.238.2017.11.27.21.27.24; Mon, 27 Nov 2017 21:27:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751248AbdK1F0r convert rfc822-to-8bit (ORCPT + 77 others); Tue, 28 Nov 2017 00:26:47 -0500 Received: from prv-mh.provo.novell.com ([137.65.248.74]:60153 "EHLO prv-mh.provo.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750793AbdK1F0p (ORCPT ); Tue, 28 Nov 2017 00:26:45 -0500 Received: from INET-PRV-MTA by prv-mh.provo.novell.com with Novell_GroupWise; Mon, 27 Nov 2017 22:26:44 -0700 Message-Id: <5A1D640C020000F90009ACC8@prv-mh.provo.novell.com> X-Mailer: Novell GroupWise Internet Agent 14.2.2 Date: Mon, 27 Nov 2017 22:26:36 -0700 From: "Gang He" To: , , , "Goldwyn Rodrigues" , Cc: , Subject: Re: [Ocfs2-devel] [PATCH 1/3] ocfs2: add ocfs2_try_rw_lock and ocfs2_try_inode_lock References: <1511775987-841-1-git-send-email-ghe@suse.com> <1511775987-841-2-git-send-email-ghe@suse.com> <63ADC13FD55D6546B7DECE290D39E373F146F95E@H3CMLB12-EX.srv.huawei-3com.com> In-Reply-To: <63ADC13FD55D6546B7DECE290D39E373F146F95E@H3CMLB12-EX.srv.huawei-3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Changwei, >>> > Hi Gang, > > On 2017/11/27 17:48, Gang He wrote: >> Add ocfs2_try_rw_lock and ocfs2_try_inode_lock functions, which >> will be used in non-block IO scenarios. >> >> Signed-off-by: Gang He >> --- >> fs/ocfs2/dlmglue.c | 22 ++++++++++++++++++++++ >> fs/ocfs2/dlmglue.h | 4 ++++ >> 2 files changed, 26 insertions(+) >> >> diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c >> index 4689940..5cfbd04 100644 >> --- a/fs/ocfs2/dlmglue.c >> +++ b/fs/ocfs2/dlmglue.c >> @@ -1742,6 +1742,28 @@ int ocfs2_rw_lock(struct inode *inode, int write) >> return status; >> } >> >> +int ocfs2_try_rw_lock(struct inode *inode, int write) >> +{ >> + int status, level; >> + struct ocfs2_lock_res *lockres; >> + struct ocfs2_super *osb = OCFS2_SB(inode->i_sb); >> + >> + mlog(0, "inode %llu try to take %s RW lock\n", >> + (unsigned long long)OCFS2_I(inode)->ip_blkno, >> + write ? "EXMODE" : "PRMODE"); >> + >> + if (ocfs2_mount_local(osb)) >> + return 0; >> + >> + lockres = &OCFS2_I(inode)->ip_rw_lockres; >> + >> + level = write ? DLM_LOCK_EX : DLM_LOCK_PR; >> + >> + status = ocfs2_cluster_lock(OCFS2_SB(inode->i_sb), lockres, level, >> + DLM_LKF_NOQUEUE, 0); >> + return status; >> +} > > The newly added function ocfs2_try_rw_lock almost has the same logic > with ocfs2_rw_lock.Is it possible to combine them into an unique one? > That will be more elegant. I prefer to keep ocfs2_try_rw_lock() separately, since there has been the similar function/code here (e.g. ocfs2_try_open_lock). second, adding a new ocfs2_try_rw_lock() function can avoid impact the existing code. > > Moreover, can you elaborate further why we need a *NOQUEUE* lock for > supporting non-block aio? Non-block IO means that the invoking should return with -EAGAIN instead of being blocked to wait for certain resource (e.g. lock, block allocation, etc.). > > Why can't we wait for a while to grant a lock request? Is this necessary? Non-block IO is a way for the upper application to submit IO, if the invoking will be blocked, the invoking will failed with -EAGAIN, then, the upper application will submit this IO with the normal (block mode) way in a delayed thread, this IO mode will benefit some database application. > > Thanks, > Changwei > >> + >> void ocfs2_rw_unlock(struct inode *inode, int write) >> { >> int level = write ? DLM_LOCK_EX : DLM_LOCK_PR; >> diff --git a/fs/ocfs2/dlmglue.h b/fs/ocfs2/dlmglue.h >> index a7fc18b..05910fc 100644 >> --- a/fs/ocfs2/dlmglue.h >> +++ b/fs/ocfs2/dlmglue.h >> @@ -116,6 +116,7 @@ void ocfs2_refcount_lock_res_init(struct ocfs2_lock_res > *lockres, >> int ocfs2_create_new_inode_locks(struct inode *inode); >> int ocfs2_drop_inode_locks(struct inode *inode); >> int ocfs2_rw_lock(struct inode *inode, int write); >> +int ocfs2_try_rw_lock(struct inode *inode, int write); >> void ocfs2_rw_unlock(struct inode *inode, int write); >> int ocfs2_open_lock(struct inode *inode); >> int ocfs2_try_open_lock(struct inode *inode, int write); >> @@ -140,6 +141,9 @@ int ocfs2_inode_lock_with_page(struct inode *inode, >> /* 99% of the time we don't want to supply any additional flags -- >> * those are for very specific cases only. */ >> #define ocfs2_inode_lock(i, b, e) ocfs2_inode_lock_full_nested(i, b, e, 0, > OI_LS_NORMAL) >> +#define ocfs2_try_inode_lock(i, b, e)\ >> + ocfs2_inode_lock_full_nested(i, b, e, OCFS2_META_LOCK_NOQUEUE,\ >> + OI_LS_NORMAL) >> void ocfs2_inode_unlock(struct inode *inode, >> int ex); >> int ocfs2_super_lock(struct ocfs2_super *osb, >> From 1585285021771558776@xxx Tue Nov 28 05:06:49 +0000 2017 X-GM-THRID: 1585212200939154586 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread