Re: [RFC PATCH v2 00/13] Add futex2 syscall

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Peter,

Às 02:44 de 04/03/21, Peter Oskolkov escreveu:
On Wed, Mar 3, 2021 at 5:22 PM André Almeida <andrealmeid@xxxxxxxxxxxxx> wrote:

Hi,

This patch series introduces the futex2 syscalls.

* FAQ

  ** "And what's about FUTEX_64?"

  By supporting 64 bit futexes, the kernel structure for futex would
  need to have a 64 bit field for the value, and that could defeat one of
  the purposes of having different sized futexes in the first place:
  supporting smaller ones to decrease memory usage. This might be
  something that could be disabled for 32bit archs (and even for
  CONFIG_BASE_SMALL).

  Which use case would benefit for FUTEX_64? Does it worth the trade-offs?

The ability to store a pointer value on 64bit platforms is an
important use case.
Imagine a simple producer/consumer scenario, with the producer updating
some shared memory data and waking the consumer. Storing the pointer
in the futex makes it so that only one shared memory location needs to be
accessed "atomically", etc. With two atomics synchronization becomes
more involved (= slower).


So the idea is to, instead of doing this:

T1:
atomic_set(&shm_addr, buffer_addr);
atomic_set(&futex, 0);
futex_wake(&futex, 1);

T2:
consume(shm_addr);

To do that:

T1:
atomic_set(&futex, buffer_addr);
futex_wake(&futex, 1);

T2:
consume(futex);

Right?

I'll try to write a small test to see how the perf numbers looks like.



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux