Re: [RFC][PATCH] sched/wait_bit: Introduce wait_var_event()/wake_up_var()

On Thu, Mar 15, 2018 at 02:45:20PM +, David Howells wrote: > Peter Zijlstra wrote: > > > Does the below address things sufficiently clear? > > Yep. Thanks! > > +wait_queue_head_t *__var_waitqueue(void *p) > > +{ > > + if (BITS_PER_LONG == 64) { > > +

Re: [RFC][PATCH] sched/wait_bit: Introduce wait_var_event()/wake_up_var()

On Thu, Mar 15, 2018 at 02:45:20PM +, David Howells wrote: > Peter Zijlstra wrote: > > > Does the below address things sufficiently clear? > > Yep. Thanks! > > +wait_queue_head_t *__var_waitqueue(void *p) > > +{ > > + if (BITS_PER_LONG == 64) { > > + unsigned long q =

Re: [RFC][PATCH] sched/wait_bit: Introduce wait_var_event()/wake_up_var()

Peter Zijlstra wrote: > Does the below address things sufficiently clear? Yep. > +wait_queue_head_t *__var_waitqueue(void *p) > +{ > + if (BITS_PER_LONG == 64) { > + unsigned long q = (unsigned long)p; > + > + return bit_waitqueue((void *)(q &

Re: [RFC][PATCH] sched/wait_bit: Introduce wait_var_event()/wake_up_var()

Peter Zijlstra wrote: > Does the below address things sufficiently clear? Yep. > +wait_queue_head_t *__var_waitqueue(void *p) > +{ > + if (BITS_PER_LONG == 64) { > + unsigned long q = (unsigned long)p; > + > + return bit_waitqueue((void *)(q & ~1), q & 1); > + }

Re: [RFC][PATCH] sched/wait_bit: Introduce wait_var_event()/wake_up_var()

On Thu, Mar 15, 2018 at 09:58:42AM +, David Howells wrote: > Peter Zijlstra wrote: > > > > > Argh, no no no.. That whole wait_for_atomic_t thing is a giant > > > > trainwreck already and now you're making it worse still. > > Your patch description needs to say why this

Re: [RFC][PATCH] sched/wait_bit: Introduce wait_var_event()/wake_up_var()

On Thu, Mar 15, 2018 at 09:58:42AM +, David Howells wrote: > Peter Zijlstra wrote: > > > > > Argh, no no no.. That whole wait_for_atomic_t thing is a giant > > > > trainwreck already and now you're making it worse still. > > Your patch description needs to say why this isn't a trainwreck

Re: [RFC][PATCH] sched/wait_bit: Introduce wait_var_event()/wake_up_var()

On Thu, Mar 15, 2018 at 09:58:42AM +, David Howells wrote: > Peter Zijlstra wrote: > > > > > Argh, no no no.. That whole wait_for_atomic_t thing is a giant > > > > trainwreck already and now you're making it worse still. > > Your patch description needs to say why this

Re: [RFC][PATCH] sched/wait_bit: Introduce wait_var_event()/wake_up_var()

On Thu, Mar 15, 2018 at 09:58:42AM +, David Howells wrote: > Peter Zijlstra wrote: > > > > > Argh, no no no.. That whole wait_for_atomic_t thing is a giant > > > > trainwreck already and now you're making it worse still. > > Your patch description needs to say why this isn't a trainwreck

Re: [RFC][PATCH] sched/wait_bit: Introduce wait_var_event()/wake_up_var()

Peter Zijlstra wrote: > > > Argh, no no no.. That whole wait_for_atomic_t thing is a giant > > > trainwreck already and now you're making it worse still. Your patch description needs to say why this isn't a trainwreck when you consider wait_for_atomic_t() to be one since

Re: [RFC][PATCH] sched/wait_bit: Introduce wait_var_event()/wake_up_var()

Peter Zijlstra wrote: > > > Argh, no no no.. That whole wait_for_atomic_t thing is a giant > > > trainwreck already and now you're making it worse still. Your patch description needs to say why this isn't a trainwreck when you consider wait_for_atomic_t() to be one since it does things in a

Re: [RFC][PATCH] sched/wait_bit: Introduce wait_var_event()/wake_up_var()

On Tue, Mar 13, 2018 at 3:20 AM, Peter Zijlstra wrote: > On Sun, Mar 11, 2018 at 10:15:55AM -0700, Dan Williams wrote: >> On Sun, Mar 11, 2018 at 4:27 AM, Peter Zijlstra wrote: >> > On Fri, Mar 09, 2018 at 10:55:32PM -0800, Dan Williams wrote: >> >>

Re: [RFC][PATCH] sched/wait_bit: Introduce wait_var_event()/wake_up_var()

On Tue, Mar 13, 2018 at 3:20 AM, Peter Zijlstra wrote: > On Sun, Mar 11, 2018 at 10:15:55AM -0700, Dan Williams wrote: >> On Sun, Mar 11, 2018 at 4:27 AM, Peter Zijlstra wrote: >> > On Fri, Mar 09, 2018 at 10:55:32PM -0800, Dan Williams wrote: >> >> Add a generic facility for awaiting an

Re: [RFC][PATCH] sched/wait_bit: Introduce wait_var_event()/wake_up_var()

On Tue, Mar 13, 2018 at 3:20 AM, Peter Zijlstra wrote: > On Sun, Mar 11, 2018 at 10:15:55AM -0700, Dan Williams wrote: >> On Sun, Mar 11, 2018 at 4:27 AM, Peter Zijlstra wrote: >> > On Fri, Mar 09, 2018 at 10:55:32PM -0800, Dan Williams wrote: >> >>

Re: [RFC][PATCH] sched/wait_bit: Introduce wait_var_event()/wake_up_var()

On Tue, Mar 13, 2018 at 3:20 AM, Peter Zijlstra wrote: > On Sun, Mar 11, 2018 at 10:15:55AM -0700, Dan Williams wrote: >> On Sun, Mar 11, 2018 at 4:27 AM, Peter Zijlstra wrote: >> > On Fri, Mar 09, 2018 at 10:55:32PM -0800, Dan Williams wrote: >> >> Add a generic facility for awaiting an

[RFC][PATCH] sched/wait_bit: Introduce wait_var_event()/wake_up_var()

On Sun, Mar 11, 2018 at 10:15:55AM -0700, Dan Williams wrote: > On Sun, Mar 11, 2018 at 4:27 AM, Peter Zijlstra wrote: > > On Fri, Mar 09, 2018 at 10:55:32PM -0800, Dan Williams wrote: > >> Add a generic facility for awaiting an atomic_t to reach a value of 1. > >> > >> Page

[RFC][PATCH] sched/wait_bit: Introduce wait_var_event()/wake_up_var()

On Sun, Mar 11, 2018 at 10:15:55AM -0700, Dan Williams wrote: > On Sun, Mar 11, 2018 at 4:27 AM, Peter Zijlstra wrote: > > On Fri, Mar 09, 2018 at 10:55:32PM -0800, Dan Williams wrote: > >> Add a generic facility for awaiting an atomic_t to reach a value of 1. > >> > >> Page reference counts