On Tue, Aug 06, 2019 at 02:26:38AM -0400, Gabriel Krisman Bertazi wrote:
> Peter Zijlstra writes:
>
> >
> >> +static int futex_wait_multiple(u32 __user *uaddr, unsigned int flags,
> >> + u32 count, ktime_t *abs_time)
> >> +{
> >> + struct futex_wait_block *wb;
> >> + str
Peter Zijlstra writes:
>
>> +static int futex_wait_multiple(u32 __user *uaddr, unsigned int flags,
>> + u32 count, ktime_t *abs_time)
>> +{
>> +struct futex_wait_block *wb;
>> +struct restart_block *restart;
>> +int ret;
>> +
>> +if (!count)
>> +
On 7/31/19 6:32 PM, Zebediah Figura wrote:
On 7/31/19 8:22 PM, Zebediah Figura wrote:
On 7/31/19 7:45 PM, Thomas Gleixner wrote:
If I assume a maximum of 65 futexes which got mentioned in one of the
replies then this will allocate 7280 bytes alone for the futex_q
array with
a stock debian conf
On 7/31/19 8:22 PM, Zebediah Figura wrote:
On 7/31/19 7:45 PM, Thomas Gleixner wrote:
If I assume a maximum of 65 futexes which got mentioned in one of the
replies then this will allocate 7280 bytes alone for the futex_q array with
a stock debian config which has no debug options enabled which w
On 7/31/19 7:45 PM, Thomas Gleixner wrote:
If I assume a maximum of 65 futexes which got mentioned in one of the
replies then this will allocate 7280 bytes alone for the futex_q array with
a stock debian config which has no debug options enabled which would bloat
the struct. Adding the futex_wait
On Tue, 30 Jul 2019, Gabriel Krisman Bertazi wrote:
> + retry:
> + for (i = 0; i < count; i++) {
> + qs[i].key = FUTEX_KEY_INIT;
> + qs[i].bitset = wb[i].bitset;
> +
> + ret = get_futex_key(wb[i].uaddr, flags & FLAGS_SHARED,
> +
On 7/31/19 5:39 PM, Thomas Gleixner wrote:
On Wed, 31 Jul 2019, Zebediah Figura wrote:
On 7/31/19 7:06 AM, Peter Zijlstra wrote:
On Tue, Jul 30, 2019 at 06:06:02PM -0400, Gabriel Krisman Bertazi wrote:
This is a new futex operation, called FUTEX_WAIT_MULTIPLE, which allows
a thread to wait on
On Wed, 31 Jul 2019, Zebediah Figura wrote:
> On 7/31/19 7:06 AM, Peter Zijlstra wrote:
> > On Tue, Jul 30, 2019 at 06:06:02PM -0400, Gabriel Krisman Bertazi wrote:
> > > This is a new futex operation, called FUTEX_WAIT_MULTIPLE, which allows
> > > a thread to wait on several futexes at the same ti
On 7/31/19 7:06 AM, Peter Zijlstra wrote:
On Tue, Jul 30, 2019 at 06:06:02PM -0400, Gabriel Krisman Bertazi wrote:
This is a new futex operation, called FUTEX_WAIT_MULTIPLE, which allows
a thread to wait on several futexes at the same time, and be awoken by
any of them. In a sense, it implement
On Tue, Jul 30, 2019 at 06:06:02PM -0400, Gabriel Krisman Bertazi wrote:
> This is a new futex operation, called FUTEX_WAIT_MULTIPLE, which allows
> a thread to wait on several futexes at the same time, and be awoken by
> any of them. In a sense, it implements one of the features that was
> suppor
This is a new futex operation, called FUTEX_WAIT_MULTIPLE, which allows
a thread to wait on several futexes at the same time, and be awoken by
any of them. In a sense, it implements one of the features that was
supported by pooling on the old FUTEX_FD interface.
My use case for this operation lie
11 matches
Mail list logo
