[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ae5b077863fb4853b4f26c3f0b176ac0@AcuMS.aculab.com>
Date: Wed, 9 Jun 2021 16:26:09 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Peter Zijlstra' <peterz@...radead.org>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>
CC: André Almeida <andrealmeid@...labora.com>,
"Nicholas Piggin" <npiggin@...il.com>,
"acme@...nel.org" <acme@...nel.org>,
"Andrey Semashev" <andrey.semashev@...il.com>,
"corbet@....net" <corbet@....net>,
Davidlohr Bueso <dave@...olabs.net>,
Darren Hart <dvhart@...radead.org>,
"fweimer@...hat.com" <fweimer@...hat.com>,
"joel@...lfernandes.org" <joel@...lfernandes.org>,
"kernel@...labora.com" <kernel@...labora.com>,
"krisman@...labora.com" <krisman@...labora.com>,
"libc-alpha@...rceware.org" <libc-alpha@...rceware.org>,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
"malteskarupke@...tmail.fm" <malteskarupke@...tmail.fm>,
Ingo Molnar <mingo@...hat.com>,
"pgriffais@...vesoftware.com" <pgriffais@...vesoftware.com>,
Peter Oskolkov <posk@...k.io>,
Steven Rostedt <rostedt@...dmis.org>,
"shuah@...nel.org" <shuah@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
"z.figura12@...il.com" <z.figura12@...il.com>
Subject: RE: [PATCH v4 00/15] Add futex2 syscalls
From: Peter Zijlstra
> Sent: 08 June 2021 15:24
...
> And if we're going to do a new interface, we ought to make one that can
> solve all these problems. Now, ideally glibc will bring forth some
> opinions, but if they don't want to play, we'll go back to the good old
> days of non-standard locking libraries.. we're halfway there already due
> to glibc not wanting to break with POSIX were we know POSIX was just
> dead wrong broken.
I had a problem with pthread_broadcast().
I've got multiple threads all bound to different cpu and
I really do want to wake them all up at once.
Now, I know they'll spin on the mutex for a bit - but that
is soon released (the 'adaptive' spin is probably long enough).
But what actually happens (probably because of the way glibc
is constrained by the futext system call) is:
1) The first thread is woken.
2) It's cpu comes out of sleep.
3) Once running it wakes the second thread.
4) It's cpu comes out of sleep.
...
So you get a very slow ripple of the threads starting.
Worse still, if the thread can't be scheduled (eg because
its cpu is running all the network stack softint code)
then none of the later threads start running.
I've mitigated it by using a separate cv for each thread
and looping to wake them all - but it shouldn't really
be necessary.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists