On Mon, May 30, 2016 at 03:59:51PM +0200, Sebastian Andrzej Siewior wrote:
> On 05/30/2016 03:49 PM, Peter Zijlstra wrote:
> >> The same thing can happen within a Task if you take my story from above
> >> and replace task with thread. Completely understood.
> >
> > Right; so I don't see the point
On 05/30/2016 03:49 PM, Peter Zijlstra wrote:
>> The same thing can happen within a Task if you take my story from above
>> and replace task with thread. Completely understood.
>
> Right; so I don't see the point of PREALLOCATE_HASH to cater for RT
> workloads if it still doesn't guarantee anythin
On Mon, May 30, 2016 at 03:37:48PM +0200, Sebastian Andrzej Siewior wrote:
> Yes, I did not try to discuss the hash collision away. From RT's point
> of view the problems I am aware are of the following scenario:
> Task #1 pinned to CPU1 task #2 pinned to CPU2 but share the same
> bucket. Task #2 g
On 05/30/2016 02:06 PM, Peter Zijlstra wrote:
>> We
>> never rehash the hash. To rehash the hash on runtime we would need an
>> empty futex hash and some locking in the fast path.
>
> Nah; you can do lockless rehashing. Little tricky, but entirely doable.
> At worst we'd need an rcu_read_lock(), b
On Mon, May 30, 2016 at 01:08:53PM +0200, Sebastian Andrzej Siewior wrote:
> > So I think there's a number of cases:
> >
> > - PREALLOC_HASH finds a taken bucket; in this case we can simply return
> >an error.
> > - PREALLOC_HASH succeeds, but an on demand hash later hits the same
> >buc
On 05/30/2016 10:58 AM, Peter Zijlstra wrote:
> On Fri, May 27, 2016 at 07:10:01PM +0200, Sebastian Andrzej Siewior wrote:
>> On 2016-05-19 14:24:06 [+0200], Peter Zijlstra wrote:
>>> On Thu, May 05, 2016 at 08:44:04PM -, Thomas Gleixner wrote:
+static struct futex_hash_bucket *hash_futex(
On Fri, May 27, 2016 at 07:10:01PM +0200, Sebastian Andrzej Siewior wrote:
> On 2016-05-19 14:24:06 [+0200], Peter Zijlstra wrote:
> > On Thu, May 05, 2016 at 08:44:04PM -, Thomas Gleixner wrote:
> > > +static struct futex_hash_bucket *hash_futex(union futex_key *key)
> > > +{
> > > +#ifdef CON
On Fri, May 27, 2016 at 06:52:11PM +0200, Sebastian Andrzej Siewior wrote:
> On 2016-05-19 14:21:48 [+0200], Peter Zijlstra wrote:
> > > +static void futex_populate_hash(unsigned int hash_bits)
> > > +{
> …
> > > + raw_spin_lock(&mm->futex_hash.lock);
> > > + /* We might have raced with another tas
On 2016-05-19 14:24:06 [+0200], Peter Zijlstra wrote:
> On Thu, May 05, 2016 at 08:44:04PM -, Thomas Gleixner wrote:
> > +static struct futex_hash_bucket *hash_futex(union futex_key *key)
> > +{
> > +#ifdef CONFIG_FUTEX_PRIVATE_HASH
> > + struct mm_struct *mm = current->mm;
> > + unsigned i
On 2016-05-19 14:21:48 [+0200], Peter Zijlstra wrote:
> > +static void futex_populate_hash(unsigned int hash_bits)
> > +{
…
> > + raw_spin_lock(&mm->futex_hash.lock);
> > + /* We might have raced with another task allocating the hash. */
> > + if (!mm->futex_hash.hash) {
> > + mm->f
On 2016-05-07 10:44:39 [+0200], Thomas Gleixner wrote:
> On Fri, 6 May 2016, Darren Hart wrote:
> > On Thu, May 05, 2016 at 08:44:04PM -, Thomas Gleixner wrote:
> Sure, we need to serialize attempts to populate the hash. Especially in the
> non preallocated case. The thing with raw vs. non raw
On Thu, May 05, 2016 at 08:44:04PM -, Thomas Gleixner wrote:
> +static struct futex_hash_bucket *hash_futex(union futex_key *key)
> +{
> +#ifdef CONFIG_FUTEX_PRIVATE_HASH
> + struct mm_struct *mm = current->mm;
> + unsigned int slot;
> +
> + /*
> + * Futexes which use the per p
On Thu, May 05, 2016 at 08:44:04PM -, Thomas Gleixner wrote:
> +struct futex_hash {
> + struct raw_spinlock lock;
raw_spinlock_t ?
> + unsigned inthash_bits;
> + struct futex_hash_bucket*hash;
> +};
> +static void futex_populate_has
On Sat, May 07, 2016 at 10:44:39AM +0200, Thomas Gleixner wrote:
> On Fri, 6 May 2016, Darren Hart wrote:
> > On Thu, May 05, 2016 at 08:44:04PM -, Thomas Gleixner wrote:
> > > --- /dev/null
> > > +++ b/include/linux/futex_types.h
> > > @@ -0,0 +1,12 @@
> > > +#ifndef _LINUX_FUTEX_TYPES_H
> > >
On Sat, May 07, 2016 at 10:45:57AM +0200, Thomas Gleixner wrote:
> On Fri, 6 May 2016, Darren Hart wrote:
> > It would be good to have a way to detect that the process private hash
> table was
> > > successfully created. Perhaps a /proc/pid/ feature? This would allow us
> > > to write
> > > a fu
On Fri, 6 May 2016, Darren Hart wrote:
> It would be good to have a way to detect that the process private hash table
> was
> > successfully created. Perhaps a /proc/pid/ feature? This would allow us to
> > write
> > a functional futex test for tools/testing/selftests/futex
>
> I suppose we co
On Fri, 6 May 2016, Darren Hart wrote:
> On Thu, May 05, 2016 at 08:44:04PM -, Thomas Gleixner wrote:
> > --- /dev/null
> > +++ b/include/linux/futex_types.h
> > @@ -0,0 +1,12 @@
> > +#ifndef _LINUX_FUTEX_TYPES_H
> > +#define _LINUX_FUTEX_TYPES_H
> > +
> > +struct futex_hash_bucket;
> > +
> > +
On Fri, May 06, 2016 at 11:09:33AM -0700, Darren Hart wrote:
> On Thu, May 05, 2016 at 08:44:04PM -, Thomas Gleixner wrote:
> > From: Sebastian Siewior
> >
> > The standard futex mechanism in the Linux kernel uses a global hash to store
> > transient state. Collisions on that hash can lead to
On Thu, May 05, 2016 at 08:44:04PM -, Thomas Gleixner wrote:
> From: Sebastian Siewior
>
> The standard futex mechanism in the Linux kernel uses a global hash to store
> transient state. Collisions on that hash can lead to performance degradation
> especially on NUMA systems and on real-time
From: Sebastian Siewior
The standard futex mechanism in the Linux kernel uses a global hash to store
transient state. Collisions on that hash can lead to performance degradation
especially on NUMA systems and on real-time enabled kernels even to priority
inversions.
To mitigate that problem we p
From: Sebastian Siewior
The standard futex mechanism in the Linux kernel uses a global hash to store
transient state. Collisions on that hash can lead to performance degradation
especially on NUMA systems and on real-time enabled kernels even to priority
inversions.
To mitigate that problem we p
21 matches
Mail list logo
