From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933358AbcIFI74 (ORCPT ); Tue, 6 Sep 2016 04:59:56 -0400 Received: from merlin.infradead.org ([205.233.59.134]:35418 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753413AbcIFI7w (ORCPT ); Tue, 6 Sep 2016 04:59:52 -0400 Date: Tue, 6 Sep 2016 10:59:42 +0200 From: Peter Zijlstra To: Andreas Mohr Cc: der.herr@hofr.at, Al Viro , mingo@redhat.com, torvalds@linux-foundation.org, dave@stgolabs.net, Oleg Nesterov , riel@redhat.com, tj@kernel.org, paulmck@linux.vnet.ibm.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/7] fs/locks: Replace lg_global with a percpu-rwsem Message-ID: <20160906085942.GH10153@twins.programming.kicks-ass.net> References: <20160906015800.GA31162@rhlx01.hs-esslingen.de> <20160906082328.GF10153@twins.programming.kicks-ass.net> <20160906083601.GA4964@rhlx01.hs-esslingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160906083601.GA4964@rhlx01.hs-esslingen.de> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 06, 2016 at 10:36:01AM +0200, Andreas Mohr wrote: > There might be further archives (other than gmane.org or some such), > however so far lkml.org seemed to be quite ok > and with IMHO better usability than some others Agreed, in that I liked the interface best too, however: > (although it has degraded a lot indeed in recent times, > judging from > many server/connection issues and > not listing details any more due to SPAM etc.). this has gotten to the point where it often simply doesn't show messages anymore, threads are incomplete etc.. > > > A possibly good way to commit-micro-manage this would be: > > > 1. commit shoves things into a newly created encapsulation/wrapper helper > > > stuff_lock(&flc_lock); /* <---- naming surely can be improved here */ > > > > No, because not all instances of flc_flock need the percpu-rwsem held, > > creating such a wrapper could mistakenly create the impression it > > should. > > OK, that aspect sounds valid. > However with a helper appropriately named to be focussing on > that use case (protecting that section communication), > it might be less of a concern. Dunno, I'd struggling to come up with a sensible name for such a construct. I'll leave that to others. If it really is desired we can always do so later.