Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 14 Jan 2019 10:51:53 +0100
From:   Greg Kroah-Hartman <greg@kroah.com>
To:     Hugo Lefeuvre <hle@owl.eu.com>, Greg Hartman <ghartman@google.com>,
        Alistair Strachan <astrachan@google.com>
Cc:     Arve =?iso-8859-1?B?SGr4bm5lduVn?= <arve@android.com>,
        Riley Andrews <riandrews@android.com>,
        Todd Kjos <tkjos@android.com>,
        Martijn Coenen <maco@android.com>,
        Joel Fernandes <joel@joelfernandes.org>,
        Christian Brauner <christian@brauner.io>,
        devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: staging/android: questions regarding TODO entries
Message-ID: <20190114095153.GA29722@kroah.com>
References: <20190114082715.GB3017@hle-laptop.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190114082715.GB3017@hle-laptop.local>
User-Agent: Mutt/1.11.2 (2019-01-07)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Jan 14, 2019 at 09:27:15AM +0100, Hugo Lefeuvre wrote:
> Hi,
> 
> This todo entry from staging/android/TODO intriguates me:
> 
>     vsoc.c, uapi/vsoc_shm.h
>      - The current driver uses the same wait queue for all of the futexes in a
>        region. This will cause false wakeups in regions with a large number of
>        waiting threads. We should eventually use multiple queues and select the
>        queue based on the region.
> 
> I am not sure to understand it very well.
> 
> What does "select the queue based on the region" mean here ? We already
> have one queue per region, right ?
> 
> What I understand: there is one wait queue per region, meaning that if
> threads T1 to Tn are waiting at offsets O1 to On (same region), then a
> wakeup at offset Om will wake them all. In this case there is a perf issue
> because only Tm (waiting for changes at offset Om) really wants to be
> waken up here, the rest is a bunch of spurious wakeups.
> 
> Does the todo suggest to have one queue per offset ?
> 
> Also, this comment (drivers/staging/android/vsoc.c) mentions a worst case
> of ten threads:
> 
>     /*
>      * TODO(b/73664181): Use multiple futex wait queues.
>      * We need to wake every sleeper when the condition changes. Typically
>      * only a single thread will be waiting on the condition, but there
>      * are exceptions. The worst case is about 10 threads.
>      */
> 
> It is not clear to me how this value has been obtained, nor under which
> conditions it might be true. There is no maximum to the number of threads
> fitting in the wait queue, so how can we be sure that at most ten threads
> will wait at the same offset ?
> 
> second, unrelated question:
> 
> In the VSOC_SELF_INTERRUPT ioctl (which might be removed in the future if
> VSOC_WAIT_FOR_INCOMING_INTERRUPT disappears, right ?), incoming_signalled
> is set to 1 but at no other place in the driver we reset it to zero. So,
> once VSOC_SELF_INTERRUPT has been executed once,
> VSOC_WAIT_FOR_INCOMING_INTERRUPT doesn't work anymore ?
> 
> Thanks for your work !
> 
> cheers,
> Hugo
> 
> PS: cc-ing the result of get_maintainer.pl + contacts from todo. Please
> tell me if this is not the right way to go.

Yes, it is the right thing to do but for some reason Greg Hartman (who
wrote the code) and Alistair (who knows the code better than I), were
not included in that list.  I've added them to the to: now...

Either of them can answer these questions better than I can, as I have
no idea what this code does anymore.  They are the ones who worked on
it.

thanks,

greg k-h