On Tue, Nov 17, 2020 at 10:29AM +0100, Peter Zijlstra wrote:
[...]
> > Now the million dollar question is why KCSAN hasn't run into this. Hrmph.
>
> kernel/sched/Makefile:KCSAN_SANITIZE := n
>
> might have something to do with that, I suppose.
For the record, I tried to reproduce this data
On 18/11/20 08:05, Peter Zijlstra wrote:
> On Tue, Nov 17, 2020 at 07:32:16PM +, Valentin Schneider wrote:
>>
>> On 17/11/20 16:13, Peter Zijlstra wrote:
>> > On Tue, Nov 17, 2020 at 03:37:24PM +, Valentin Schneider wrote:
>> >
>> >> >> + /*
>> >> >> + * This field must not
On Tue, Nov 17, 2020 at 07:32:16PM +, Valentin Schneider wrote:
>
> On 17/11/20 16:13, Peter Zijlstra wrote:
> > On Tue, Nov 17, 2020 at 03:37:24PM +, Valentin Schneider wrote:
> >
> >> >> + /*
> >> >> +* This field must not be in the scheduler word above due to
> >> >>
On 17/11/20 16:13, Peter Zijlstra wrote:
> On Tue, Nov 17, 2020 at 03:37:24PM +, Valentin Schneider wrote:
>
>> >> + /*
>> >> + * This field must not be in the scheduler word above due to wakelist
>> >> + * queueing no longer being serialized by p->on_cpu. However:
>> >> + *
>> >> + *
On Tue, Nov 17, 2020 at 03:37:24PM +, Valentin Schneider wrote:
> >> + /*
> >> + * This field must not be in the scheduler word above due to wakelist
> >> + * queueing no longer being serialized by p->on_cpu. However:
> >> + *
> >> + * p->XXX = X; ttwu()
> >> + *
On 17/11/20 12:52, Valentin Schneider wrote:
> On 17/11/20 09:46, Peter Zijlstra wrote:
>> How's this then? It still doesn't explicitly call out the specific race,
>> but does mention the more fundamental issue that wakelist queueing
>> doesn't respect the regular rules anymore.
>>
>> ---
On 17/11/20 09:46, Peter Zijlstra wrote:
> How's this then? It still doesn't explicitly call out the specific race,
> but does mention the more fundamental issue that wakelist queueing
> doesn't respect the regular rules anymore.
>
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@
On Tue, Nov 17, 2020 at 09:30:16AM +0100, Peter Zijlstra wrote:
> > sched_psi_wake_requeue can probably stay with the other three fields
> > given they are under the rq lock but sched_remote_wakeup needs to move
> > out.
>
> I _think_ we can move the bit into the unserialized section below.
>
>
On Tue, Nov 17, 2020 at 10:46:21AM +0100, Peter Zijlstra wrote:
> On Tue, Nov 17, 2020 at 10:29:36AM +0100, Peter Zijlstra wrote:
> > On Tue, Nov 17, 2020 at 09:15:46AM +, Will Deacon wrote:
> > > On Tue, Nov 17, 2020 at 09:30:16AM +0100, Peter Zijlstra wrote:
> > > > /* Unserialized,
On Tue, Nov 17, 2020 at 10:29:36AM +0100, Peter Zijlstra wrote:
> On Tue, Nov 17, 2020 at 09:15:46AM +, Will Deacon wrote:
> > On Tue, Nov 17, 2020 at 09:30:16AM +0100, Peter Zijlstra wrote:
> > > /* Unserialized, strictly 'current' */
> > >
> > > + /*
> > > + * p->in_iowait = 1;
On Tue, Nov 17, 2020 at 09:15:46AM +, Will Deacon wrote:
> On Tue, Nov 17, 2020 at 09:30:16AM +0100, Peter Zijlstra wrote:
> > Subject: sched: Fix data-race in wakeup
> > From: Peter Zijlstra
> > Date: Tue Nov 17 09:08:41 CET 2020
> >
> > Mel reported that on some ARM64 platforms loadavg
On Tue, Nov 17, 2020 at 09:30:16AM +0100, Peter Zijlstra wrote:
> On Mon, Nov 16, 2020 at 07:31:49PM +, Mel Gorman wrote:
>
> > And this works.
>
> Yay!
>
> > sched_psi_wake_requeue can probably stay with the other three fields
> > given they are under the rq lock but sched_remote_wakeup
On Mon, Nov 16, 2020 at 07:31:49PM +, Mel Gorman wrote:
> And this works.
Yay!
> sched_psi_wake_requeue can probably stay with the other three fields
> given they are under the rq lock but sched_remote_wakeup needs to move
> out.
I _think_ we can move the bit into the unserialized section
13 matches
Mail list logo
