On Mon, Sep 09, 2019 at 07:22:15AM -0500, Eric W. Biederman wrote:
> Let me see if I can explain my confusion in terms of task_numa_compare.
>
> The function task_numa_comare now does:
>
> rcu_read_lock();
> cur = rcu_dereference(dst_rq->curr);
>
> Then it proceeds to examine a few
Peter Zijlstra writes:
> On Thu, Sep 05, 2019 at 03:02:49PM -0500, Eric W. Biederman wrote:
>> Paul, what is the purpose of the barrier in rcu_assign_pointer?
>>
>> My intuition says it is the assignment half of rcu_dereference, and that
>> anything that rcu_dereference does not need is too stro
On Thu, Sep 05, 2019 at 03:02:49PM -0500, Eric W. Biederman wrote:
> Paul, what is the purpose of the barrier in rcu_assign_pointer?
>
> My intuition says it is the assignment half of rcu_dereference, and that
> anything that rcu_dereference does not need is too strong.
I see that Paul has also r
On Thu, Sep 05, 2019 at 03:02:49PM -0500, Eric W. Biederman wrote:
> "Paul E. McKenney" writes:
>
> > On Tue, Sep 03, 2019 at 10:06:03PM +0200, Peter Zijlstra wrote:
> >> On Tue, Sep 03, 2019 at 12:18:47PM -0700, Linus Torvalds wrote:
> >> > Now, if you can point to some particular field where th
"Paul E. McKenney" writes:
> On Tue, Sep 03, 2019 at 10:06:03PM +0200, Peter Zijlstra wrote:
>> On Tue, Sep 03, 2019 at 12:18:47PM -0700, Linus Torvalds wrote:
>> > Now, if you can point to some particular field where that ordering
>> > makes sense for the particular case of "make it active on th
On Mon, Sep 02, 2019 at 11:52:01PM -0500, Eric W. Biederman wrote:
>
> In the ordinary case today the rcu grace period of a task comes when a
> task is reaped, well after the task has left the runqueue. This
> change guarantees that the rcu grace period always happens after a
> task has left the
On Tue, Sep 03, 2019 at 10:06:03PM +0200, Peter Zijlstra wrote:
> On Tue, Sep 03, 2019 at 12:18:47PM -0700, Linus Torvalds wrote:
> > Now, if you can point to some particular field where that ordering
> > makes sense for the particular case of "make it active on the
> > runqueue" vs "look up the ta
On Tue, Sep 03, 2019 at 12:18:47PM -0700, Linus Torvalds wrote:
> Now, if you can point to some particular field where that ordering
> makes sense for the particular case of "make it active on the
> runqueue" vs "look up the task from the runqueue using RCU", then I do
> think that the whole releas
On Tue, Sep 03, 2019 at 01:13:22PM -0500, Eric W. Biederman wrote:
> I think this is where I am looking a things differently than you and
> Peter. Why does it have to be ___schedule() that changes the value
> in the task_struct? Why can't it be something else that changes the
> value and then pr
On Tue, Sep 3, 2019 at 11:13 AM Eric W. Biederman wrote:
>
> I think this is where I am looking a things differently than you and
> Peter. Why does it have to be ___schedule() that changes the value
> in the task_struct? Why can't it be something else that changes the
> value and then proceeds t
Linus Torvalds writes:
> On Tue, Sep 3, 2019 at 9:45 AM Eric W. Biederman
> wrote:
>>
>> So with a big fat comment explaining why it is safe we could potentially
>> use RCU_INIT_POINTER. I currently don't see where the appropriate
>> barriers are so I can not write that comment or with a clear
On Tue, Sep 3, 2019 at 9:45 AM Eric W. Biederman wrote:
>
> So with a big fat comment explaining why it is safe we could potentially
> use RCU_INIT_POINTER. I currently don't see where the appropriate
> barriers are so I can not write that comment or with a clear conscious
> write the code to use
Peter Zijlstra writes:
> On Tue, Sep 03, 2019 at 09:41:17AM +0200, Peter Zijlstra wrote:
>> On Mon, Sep 02, 2019 at 11:52:01PM -0500, Eric W. Biederman wrote:
>>
>> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> > index 2b037f195473..802958407369 100644
>> > --- a/kernel/sched/core.
On Tue, Sep 03, 2019 at 09:41:17AM +0200, Peter Zijlstra wrote:
> On Mon, Sep 02, 2019 at 11:52:01PM -0500, Eric W. Biederman wrote:
>
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index 2b037f195473..802958407369 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
On Mon, Sep 02, 2019 at 11:52:01PM -0500, Eric W. Biederman wrote:
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 2b037f195473..802958407369 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3857,7 +3857,7 @@ static void __sched notrace __schedule(bool preempt
In the ordinary case today the rcu grace period of a task comes when a
task is reaped, well after the task has left the runqueue. This
change guarantees that the rcu grace period always happens after a
task has left the runqueue. As this is something that usaually happens
today I do not expect
16 matches
Mail list logo
