On Mon, Aug 23, 2021 at 6:06 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> 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 <swhiteho@xxxxxxxxxx> 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? I've looked at the ww_mutex documentation. A "transaction" wounds another "transaction" and that other transaction then "dies", or it "heals" and restarts. In the glock case, a process sets and clears the HIF_MAY_DEMOTE flag on one of its own glock holder contexts. After clearing the flag, it either still holds the glock or it doesn't; nothing needs to be done to "die" or to "heal". So I'm not sure we want to conflate two concepts. One of the earlier terms we've used was "stealing", with a HIF_MAY_STEAL flag. That works, but it's slightly less obvious what happens to a glock holder when the glock is stolen from it. (The holder gets dequeued, __gfs2_glock_dq.) The glock code already uses the terms promote/demote, acquire/release, enqueue/dequeue, and _nq/_dq for various forms of acquiring and releasing a glock, so we're not in a shortage or names right now apparently. Thanks, Andreas
