Messages in this thread | | | From | Peter Oskolkov <> | Date | Thu, 23 Jul 2020 20:22:14 -0700 | Subject | Re: [PATCH for 5.9 1/3] futex: introduce FUTEX_SWAP operation |
| |
On Thu, Jul 23, 2020 at 8:00 PM Waiman Long <longman@redhat.com> wrote: > > On 7/23/20 8:25 PM, Peter Oskolkov wrote: > > On Thu, Jul 23, 2020 at 4:28 AM Peter Zijlstra <peterz@infradead.org> wrote: > > > > Thanks a lot for your comments, Peter! My answers below. > > > >> On Wed, Jul 22, 2020 at 04:45:36PM -0700, Peter Oskolkov wrote: > >>> This patchset is the first step to open-source this work. As explained > >>> in the linked pdf and video, SwitchTo API has three core operations: wait, > >>> resume, and swap (=switch). So this patchset adds a FUTEX_SWAP operation > >>> that, in addition to FUTEX_WAIT and FUTEX_WAKE, will provide a foundation > >>> on top of which user-space threading libraries can be built. > >> The PDF and video can go pound sand; you get to fully explain things > >> here. > > Will do. Should I expand the cover letter or the commit message? (I'll probably > > split the first patch into two in the latter case). > > You should put it mostly in the commit message which will be part of the > git log history. The cover letter, on the other hand, is not part of the > git log.
Ack. (Networking/David Miller usually includes the cover letter in the git log, so this is context dependent, I guess).
> > > > > >> What worries me is how FUTEX_SWAP would interact with the future > >> FUTEX_LOCK / FUTEX_UNLOCK. When we implement pthread_mutex with those, > >> there's very few WAIT/WAKE left. > > [+cc Waiman Long] > > > > I've looked through the latest FUTEX_LOCK patchset I could find ( > > https://lore.kernel.org/patchwork/cover/772643/ and related), and it seems > > that FUTEX_SWAP and FUTEX_LOCK/FUTEX_UNLOCK patchsets > > address the same issue (slow wakeups) but for different use cases: > > > > FUTEX_LOCK/FUTEX_UNLOCK uses spinning and lock stealing to > > improve futex wake/wait performance in high contention situations; > > FUTEX_SWAP is designed to be used for fast context switching with > > _no_ contention by design: the waker that is going to sleep, and the wakee > > are using different futexes; the userspace will have a futex per thread/task, > > and when needed the thread/task will either simply sleep on its futex, > > or context switch (=FUTEX_SWAP) into a different thread/task. > > I agree that it is a different use case. I just hope that you keep the > possible future extension to support FUTEX_LOCK/UNLOCK in mind so that > they won't conflict with each other.
Ack. Will do. :)
Thanks, Peter
> > Cheers, > Longman >
| |