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 <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?
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
