From: NeilBrown <neilb@suse.com> To: Oleg Drokin <oleg.drokin@intel.com>, Andreas Dilger <andreas.dilger@intel.com>, James Simmons <jsimmons@infradead.org> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Lustre Development List <lustre-devel@lists.lustre.org> Subject: RFC: [PATCH 0/6] lustre: Improve locking in lu_object.s Date: Fri, 11 May 2018 10:37:14 +1000 [thread overview] Message-ID: <152599874625.19824.11344372150811845854.stgit@noble> (raw) This is a followup to the patches that James recently posted which addressed some locking issues in lu_object.c. I said at the time that I thought the locking could be improved further. Here is the result of that thought. The lu_keys_guard lock is now gone, replaced by a spin lock, an rwsem, and some lockless code. The lu_context_exit() function, which appears to have been a performance problem at one point, is now completely lockless. This is an RFC at this stage: I haven't included Greg on the email and don't expect this to go upstream without some review - and maybe even some testing. Thanks, NeilBrown --- NeilBrown (6): staging: lustre: make key_set_version an atomic_t staging: lustre: use an rwsem instead of lu_key_initing_cnt. staging: lustre: remove locking from lu_context_exit() staging: lustre: use wait_event_var() in lu_context_key_degister() staging: lustre: remove lock from key register/degister staging: lustre: rename lu_keys_guard to lu_context_remembered_guard drivers/staging/lustre/lustre/include/lu_object.h | 1 drivers/staging/lustre/lustre/obdclass/lu_object.c | 187 ++++++++------------ 2 files changed, 78 insertions(+), 110 deletions(-) -- Signature
WARNING: multiple messages have this Message-ID (diff)
From: NeilBrown <neilb@suse.com> To: Oleg Drokin <oleg.drokin@intel.com>, Andreas Dilger <andreas.dilger@intel.com>, James Simmons <jsimmons@infradead.org> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Lustre Development List <lustre-devel@lists.lustre.org> Subject: [lustre-devel] RFC: [PATCH 0/6] lustre: Improve locking in lu_object.s Date: Fri, 11 May 2018 10:37:14 +1000 [thread overview] Message-ID: <152599874625.19824.11344372150811845854.stgit@noble> (raw) This is a followup to the patches that James recently posted which addressed some locking issues in lu_object.c. I said at the time that I thought the locking could be improved further. Here is the result of that thought. The lu_keys_guard lock is now gone, replaced by a spin lock, an rwsem, and some lockless code. The lu_context_exit() function, which appears to have been a performance problem at one point, is now completely lockless. This is an RFC at this stage: I haven't included Greg on the email and don't expect this to go upstream without some review - and maybe even some testing. Thanks, NeilBrown --- NeilBrown (6): staging: lustre: make key_set_version an atomic_t staging: lustre: use an rwsem instead of lu_key_initing_cnt. staging: lustre: remove locking from lu_context_exit() staging: lustre: use wait_event_var() in lu_context_key_degister() staging: lustre: remove lock from key register/degister staging: lustre: rename lu_keys_guard to lu_context_remembered_guard drivers/staging/lustre/lustre/include/lu_object.h | 1 drivers/staging/lustre/lustre/obdclass/lu_object.c | 187 ++++++++------------ 2 files changed, 78 insertions(+), 110 deletions(-) -- Signature
next reply other threads:[~2018-05-11 0:40 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-05-11 0:37 NeilBrown [this message] 2018-05-11 0:37 ` [lustre-devel] RFC: [PATCH 0/6] lustre: Improve locking in lu_object.s NeilBrown 2018-05-11 0:37 ` [PATCH 2/6] staging: lustre: use an rwsem instead of lu_key_initing_cnt NeilBrown 2018-05-11 0:37 ` [lustre-devel] " NeilBrown 2018-05-11 0:37 ` [PATCH 1/6] staging: lustre: make key_set_version an atomic_t NeilBrown 2018-05-11 0:37 ` [lustre-devel] " NeilBrown 2018-05-15 15:21 ` James Simmons 2018-05-15 22:51 ` NeilBrown 2018-05-11 0:37 ` [PATCH 5/6] staging: lustre: remove lock from key register/degister NeilBrown 2018-05-11 0:37 ` [lustre-devel] " NeilBrown 2018-05-11 0:37 ` [PATCH 4/6] staging: lustre: use wait_event_var() in lu_context_key_degister() NeilBrown 2018-05-11 0:37 ` [lustre-devel] " NeilBrown 2018-05-11 0:37 ` [PATCH 6/6] staging: lustre: rename lu_keys_guard to lu_context_remembered_guard NeilBrown 2018-05-11 0:37 ` [lustre-devel] " NeilBrown 2018-05-11 0:37 ` [PATCH 3/6] staging: lustre: remove locking from lu_context_exit() NeilBrown 2018-05-11 0:37 ` [lustre-devel] " NeilBrown 2018-05-15 15:42 ` [lustre-devel] RFC: [PATCH 0/6] lustre: Improve locking in lu_object.s James Simmons 2018-05-15 22:46 ` NeilBrown
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=152599874625.19824.11344372150811845854.stgit@noble \ --to=neilb@suse.com \ --cc=andreas.dilger@intel.com \ --cc=jsimmons@infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lustre-devel@lists.lustre.org \ --cc=oleg.drokin@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.