From mboxrd@z Thu Jan 1 00:00:00 1970 From: Waiman Long Subject: Re: [PATCH v4 1/1] dcache: Translating dentry into pathname without taking rename_lock Date: Mon, 09 Sep 2013 23:57:40 -0400 Message-ID: <522E98B4.1050906@hp.com> References: <20130910004020.29299.qmail@science.horizon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: torvalds@linux-foundation.org, viro@ZenIV.linux.org.uk, aswin@hp.com, john@stoffel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, scott.norton@hp.com To: George Spelvin Return-path: In-Reply-To: <20130910004020.29299.qmail@science.horizon.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On 09/09/2013 08:40 PM, George Spelvin wrote: > I'm really wondering about only trying once before taking the write lock. > Yes, using the lsbit is a cute hack, but are we using it for its cuteness > rather than its effectiveness? > > Renames happen occasionally. If that causes all the current pathname > translations to fall back to the write lock, that is fairly heavy. > Worse, all of those translations will (unnecessarily) bump the write > seqcount, triggering *other* translations to fail back to the write-lock > path. > > One patch to fix this would be to have the fallback read algorithm take > sl->lock but *not* touch sl->seqcount, so it wouldn't break concurrent > readers. Actually, a follow-up patch that I am planning to do is to introduce a read_seqlock() primitive in seqlock.h that does exactly that. Then the write_seqlock() in this patch will be modified to read_seqlock(). -Longman