linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* staging/android: questions regarding TODO entries
@ 2019-01-14  8:27 Hugo Lefeuvre
  2019-01-14  9:51 ` Greg Kroah-Hartman
  0 siblings, 1 reply; 3+ messages in thread
From: Hugo Lefeuvre @ 2019-01-14  8:27 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Arve Hjønnevåg, Riley Andrews, Todd Kjos,
	Martijn Coenen, Joel Fernandes, Christian Brauner, devel,
	linux-kernel

[-- Attachment #1: Type: text/plain, Size: 2286 bytes --]

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.

-- 
                Hugo Lefeuvre (hle)    |    www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: staging/android: questions regarding TODO entries
  2019-01-14  8:27 staging/android: questions regarding TODO entries Hugo Lefeuvre
@ 2019-01-14  9:51 ` Greg Kroah-Hartman
       [not found]   ` <CAOvepGkQbkgqA=pKhLejFYcUq2FqVOnW-6y=DdvPiSPdGw5eMg@mail.gmail.com>
  0 siblings, 1 reply; 3+ messages in thread
From: Greg Kroah-Hartman @ 2019-01-14  9:51 UTC (permalink / raw)
  To: Hugo Lefeuvre, Greg Hartman, Alistair Strachan
  Cc: Arve Hjønnevåg, Riley Andrews, Todd Kjos,
	Martijn Coenen, Joel Fernandes, Christian Brauner, devel,
	linux-kernel

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: staging/android: questions regarding TODO entries
       [not found]   ` <CAOvepGkQbkgqA=pKhLejFYcUq2FqVOnW-6y=DdvPiSPdGw5eMg@mail.gmail.com>
@ 2019-01-17 22:23     ` Hugo Lefeuvre
  0 siblings, 0 replies; 3+ messages in thread
From: Hugo Lefeuvre @ 2019-01-17 22:23 UTC (permalink / raw)
  To: Greg Hartman
  Cc: Greg Kroah-Hartman, Alistair Strachan, Arve Hjønnevåg,
	Riley Andrews, Todd Kjos, Martijn Coenen, Joel Fernandes,
	Christian Brauner, devel, linux-kernel

> It should probably say "address."

Thanks. I'm working on a few patches for staging/android, this issue will
be addressed as well.

regards,
 Hugo

-- 
                Hugo Lefeuvre (hle)    |    www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-01-17 22:23 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-14  8:27 staging/android: questions regarding TODO entries Hugo Lefeuvre
2019-01-14  9:51 ` Greg Kroah-Hartman
     [not found]   ` <CAOvepGkQbkgqA=pKhLejFYcUq2FqVOnW-6y=DdvPiSPdGw5eMg@mail.gmail.com>
2019-01-17 22:23     ` Hugo Lefeuvre

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).