linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 Hjønnevåg" <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
Date: Mon, 14 Jan 2019 10:51:53 +0100	[thread overview]
Message-ID: <20190114095153.GA29722@kroah.com> (raw)
In-Reply-To: <20190114082715.GB3017@hle-laptop.local>

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

  reply	other threads:[~2019-01-14  9:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-14  8:27 staging/android: questions regarding TODO entries Hugo Lefeuvre
2019-01-14  9:51 ` Greg Kroah-Hartman [this message]
     [not found]   ` <CAOvepGkQbkgqA=pKhLejFYcUq2FqVOnW-6y=DdvPiSPdGw5eMg@mail.gmail.com>
2019-01-17 22:23     ` Hugo Lefeuvre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190114095153.GA29722@kroah.com \
    --to=greg@kroah.com \
    --cc=arve@android.com \
    --cc=astrachan@google.com \
    --cc=christian@brauner.io \
    --cc=devel@driverdev.osuosl.org \
    --cc=ghartman@google.com \
    --cc=hle@owl.eu.com \
    --cc=joel@joelfernandes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maco@android.com \
    --cc=riandrews@android.com \
    --cc=tkjos@android.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).