On Thu, 20 Feb 2025 13:19:46 +0900
Sergey Senozhatsky <senozhatsky@xxxxxxxxxxxx> wrote:
> On (25/02/19 22:49), Waiman Long wrote:
> > On 2/19/25 9:45 PM, Sergey Senozhatsky wrote:
> > > On (25/02/20 08:09), Masami Hiramatsu wrote:
> > > > So something like this?
> > > >
> > > > unsigned int block_flags;
> > > > union {
> > > > struct mutex *mutex;
> > > > struct rwsem +rwsem;
> > > > struct rtmutex *rtmutex;
> > > > } blocked_on;
> > > >
> > > > enum {
> > > > BLOCKED_ON_MUTEX;
> > > > BLOCKED_ON_RWSEM;
> > > > BLOCKED_ON_RTMUTEX;
> > > > BLOCKED_ON_IO;
> > > > } block_reason;
> > > I totally like this and always wanted to have something simlar,
> > > something for all "sleepable" synchronization primitives, lightweight
> > > enough (memory and CPU usage wise) to run on consumer devices. I was
> > > thinking of a rhashtable where each entry represents "sleepable"
> > > primitive with a "owner" pointer and a list of "blocked on" tasks.
> > > But I'm sure you'll have a better idea.
> > >
> > > If I may add a couple of "wishes", can we also add:
> > > - completions (so that things like wait_for_completion and
> > > synchronize srcu get covered)
> > > - wait on bit (so that things like lock_buffer and so on get covered)
> >
> > Bit lock doesn't have a owner field to track the owning task.
>
> Right, so that's why I was thinking about keeping it outside in
> a hashtable. A list of owners plus a list of blocked_on per "lock",
> be it a rwsem, or a mutex, or a bit.
Hmm, how can we sync the accesses of the hashtable? We may need
spinlocks for the hashtable or use RCU list. If we use the RCU,
we may need to allocate RCU object for each time when a lock
contention happens (and use kfree_rcu() for each object).
Maybe it is better using a spinlock for each hashtable entry but
it still introduce overhead (need to check).
Thank you,
--
Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
