From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bob Peterson Date: Mon, 23 Aug 2021 11:36:10 -0500 Subject: [Cluster-devel] [PATCH v6 10/19] gfs2: Introduce flag for glock holder auto-demotion In-Reply-To: References: <20210819194102.1491495-1-agruenba@redhat.com> <20210819194102.1491495-11-agruenba@redhat.com> <5e8a20a8d45043e88013c6004636eae5dadc9be3.camel@redhat.com> <8e2ab23b93c96248b7c253dc3ea2007f5244adee.camel@redhat.com> Message-ID: <43cf01f7-1fb5-26a9-bcda-5c9748c6f32e@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On 8/23/21 11:05 AM, Matthew Wilcox wrote: > On Mon, Aug 23, 2021 at 05:18:12PM +0200, Andreas Gruenbacher wrote: >> On Mon, Aug 23, 2021 at 10:14 AM Steven Whitehouse wrote: >>> If the goal here is just to allow the glock to be held for a longer >>> period of time, but with occasional interruptions to prevent >>> starvation, then we have a potential model for this. There is >>> cond_resched_lock() which does this for spin locks. >> >> This isn't an appropriate model for what I'm trying to achieve here. >> In the cond_resched case, we know at the time of the cond_resched call >> whether or not we want to schedule. If we do, we want to drop the spin >> lock, schedule, and then re-acquire the spin lock. In the case we're >> looking at here, we want to fault in user pages. There is no way of >> knowing beforehand if the glock we're currently holding will have to >> be dropped to achieve that. In fact, it will almost never have to be >> dropped. But if it does, we need to drop it straight away to allow the >> conflicting locking request to succeed. > > It occurs to me that this is similar to the wound/wait mutexes > (include/linux/ww_mutex.h & Documentation/locking/ww-mutex-design.rst). > You want to mark the glock as woundable before faulting, and then discover > if it was wounded after faulting. Maybe sharing this terminology will > aid in understanding? > Hmm. Woundable. I like it. Andreas and I argued about the terminology but we never found a middle-ground. Perhaps this is it. Thanks, Matthew. Regards, Bob Peterson