Re: [PATCH 01/11] sched/wait: Introduce wait_var_event()

[Dan Williams]

On Thu, Mar 15, 2018 at 5:19 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> As a replacement for the wait_on_atomic_t() API provide the
> wait_var_event() API.
>
> The wait_var_event() API is based on the very same hashed-waitqueue
> idea, but doesn't care about the type (atomic_t) or the specific
> condition (atomic_read() == 0). IOW. it's much more widely
> applicable/flexible.
>
> It shares all the benefits/disadvantages of a hashed-waitqueue
> approach with the existing wait_on_atomic_t/wait_on_bit() APIs.
>
> The API is modeled after the existing wait_event() API, but instead of
> taking a wait_queue_head, it takes an address. This addresses is
> hashed to obtain a wait_queue_head from the bit_wait_table.
>
> Similar to the wait_event() API, it takes a condition expression as
> second argument and will wait until this expression becomes true.
>
> The following are (mostly) identical replacements:
>
>   wait_on_atomic_t(&my_atomic, atomic_t_wait, TASK_UNINTERRUPTIBLE);
>   wake_up_atomic_t(&my_atomic);
>
>   wait_var_event(&my_atomic, !atomic_read(&my_atomic));
>   wake_up_var(&my_atomic);
>
> The only difference is that wake_up_var() is an unconditional wakeup
> and doesn't check the previously hard-coded (atomic_read() == 0)
> condition here. This is of little concequence, since most callers are
> already conditional on atomic_dec_and_test() and the ones that are
> not, are trivial to make so.
>
> Cc: David Howells <dhowells@xxxxxxxxxx>
> Tested-by: Dan Williams <dan.j.williams@xxxxxxxxx>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
> ---
>  include/linux/wait_bit.h |   70 +++++++++++++++++++++++++++++++++++++++++++++++
>  kernel/sched/wait_bit.c  |   48 ++++++++++++++++++++++++++++++++
>  2 files changed, 118 insertions(+)

Hi Peter,

Is this commit ready to hit tip/sched/core? I'm looking for an
immutable branch that I can use as a basis for the "dax vs dma vs
truncate" fix series.

Thanks in advance.