* Jason Low wrote:
> On Thu, 2015-04-16 at 20:24 +0200, Ingo Molnar wrote:
> > Would it make sense to add a few comments to the seq field definition
> > site(s), about how it's supposed to be accessed - or to the
> > READ_ONCE()/WRITE_ONCE() sites, to keep people from wondering?
>
> How
* Jason Low jason.l...@hp.com wrote:
On Thu, 2015-04-16 at 20:24 +0200, Ingo Molnar wrote:
Would it make sense to add a few comments to the seq field definition
site(s), about how it's supposed to be accessed - or to the
READ_ONCE()/WRITE_ONCE() sites, to keep people from wondering?
On Thu, 2015-04-16 at 20:24 +0200, Ingo Molnar wrote:
> Would it make sense to add a few comments to the seq field definition
> site(s), about how it's supposed to be accessed - or to the
> READ_ONCE()/WRITE_ONCE() sites, to keep people from wondering?
How about this:
---
diff --git
On Thu, 2015-04-16 at 20:15 +0200, Peter Zijlstra wrote:
> On Thu, Apr 16, 2015 at 08:02:27PM +0200, Ingo Molnar wrote:
> > > ACCESS_ONCE() is not a compiler barrier
> >
> > It's not a general compiler barrier (and I didn't claim so) but it is
> > still a compiler barrier: it's documented as a
On Thu, Apr 16, 2015 at 09:02:08PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 16, 2015 at 08:24:27PM +0200, Ingo Molnar wrote:
> > Yes ... but that still leaves this weird feeling that it's really
> > still a bit wrong because it's not proper parallel code, we just
> > reduced the probability of
On Thu, Apr 16, 2015 at 08:24:27PM +0200, Ingo Molnar wrote:
> Yes ... but that still leaves this weird feeling that it's really
> still a bit wrong because it's not proper parallel code, we just
> reduced the probability of the remaining races radically. And it's not
> like GCC (or any
* Peter Zijlstra wrote:
> On Thu, Apr 16, 2015 at 08:02:27PM +0200, Ingo Molnar wrote:
> > > ACCESS_ONCE() is not a compiler barrier
> >
> > It's not a general compiler barrier (and I didn't claim so) but it is
> > still a compiler barrier: it's documented as a weak, variable specific
> >
On Thu, Apr 16, 2015 at 08:02:27PM +0200, Ingo Molnar wrote:
> > ACCESS_ONCE() is not a compiler barrier
>
> It's not a general compiler barrier (and I didn't claim so) but it is
> still a compiler barrier: it's documented as a weak, variable specific
> barrier in
* Peter Zijlstra wrote:
> On Wed, Apr 15, 2015 at 09:46:01AM +0200, Ingo Molnar wrote:
>
> > @@ -2088,7 +2088,7 @@ void task_numa_fault(int last_cpupid, int mem_node,
> int pages, int flags)
> >
> > static void reset_ptenuma_scan(struct task_struct *p)
> > {
> > -
On Wed, Apr 15, 2015 at 09:46:01AM +0200, Ingo Molnar wrote:
> @@ -2088,7 +2088,7 @@ void task_numa_fault(int last_cpupid, int mem_node,
> int pages, int flags)
>
> static void reset_ptenuma_scan(struct task_struct *p)
> {
> -ACCESS_ONCE(p->mm->numa_scan_seq)++;
> +
On Wed, Apr 15, 2015 at 09:46:01AM +0200, Ingo Molnar wrote:
@@ -2088,7 +2088,7 @@ void task_numa_fault(int last_cpupid, int mem_node,
int pages, int flags)
static void reset_ptenuma_scan(struct task_struct *p)
{
-ACCESS_ONCE(p-mm-numa_scan_seq)++;
+
* Peter Zijlstra pet...@infradead.org wrote:
On Wed, Apr 15, 2015 at 09:46:01AM +0200, Ingo Molnar wrote:
@@ -2088,7 +2088,7 @@ void task_numa_fault(int last_cpupid, int mem_node,
int pages, int flags)
static void reset_ptenuma_scan(struct task_struct *p)
{
-
On Thu, Apr 16, 2015 at 08:24:27PM +0200, Ingo Molnar wrote:
Yes ... but that still leaves this weird feeling that it's really
still a bit wrong because it's not proper parallel code, we just
reduced the probability of the remaining races radically. And it's not
like GCC (or any compiler)
On Thu, 2015-04-16 at 20:15 +0200, Peter Zijlstra wrote:
On Thu, Apr 16, 2015 at 08:02:27PM +0200, Ingo Molnar wrote:
ACCESS_ONCE() is not a compiler barrier
It's not a general compiler barrier (and I didn't claim so) but it is
still a compiler barrier: it's documented as a weak,
On Thu, Apr 16, 2015 at 09:02:08PM +0200, Peter Zijlstra wrote:
On Thu, Apr 16, 2015 at 08:24:27PM +0200, Ingo Molnar wrote:
Yes ... but that still leaves this weird feeling that it's really
still a bit wrong because it's not proper parallel code, we just
reduced the probability of the
On Thu, 2015-04-16 at 20:24 +0200, Ingo Molnar wrote:
Would it make sense to add a few comments to the seq field definition
site(s), about how it's supposed to be accessed - or to the
READ_ONCE()/WRITE_ONCE() sites, to keep people from wondering?
How about this:
---
diff --git
On Thu, Apr 16, 2015 at 08:02:27PM +0200, Ingo Molnar wrote:
ACCESS_ONCE() is not a compiler barrier
It's not a general compiler barrier (and I didn't claim so) but it is
still a compiler barrier: it's documented as a weak, variable specific
barrier in Documentation/memor-barriers.txt:
* Peter Zijlstra pet...@infradead.org wrote:
On Thu, Apr 16, 2015 at 08:02:27PM +0200, Ingo Molnar wrote:
ACCESS_ONCE() is not a compiler barrier
It's not a general compiler barrier (and I didn't claim so) but it is
still a compiler barrier: it's documented as a weak, variable
Hi Ingo,
On Wed, 2015-04-15 at 09:46 +0200, Ingo Molnar wrote:
> * Steven Rostedt wrote:
> > You are correct. Now I'm thinking that the WRITE_ONCE() is not needed,
> > and just a:
> >
> > p->mm->numa_scan_seq = READ_ONCE(p->numa_scan_seq) + 1;
> >
> > Can be done. But I'm still trying to
On Wed, 15 Apr 2015 19:29:01 -0700
Jason Low wrote:
> On Tue, 2015-04-14 at 22:40 -0400, Steven Rostedt wrote:
> > You are correct. Now I'm thinking that the WRITE_ONCE() is not needed,
> > and just a:
> >
> > p->mm->numa_scan_seq = READ_ONCE(p->numa_scan_seq) + 1;
>
> Just to confirm, is
On Tue, 2015-04-14 at 22:40 -0400, Steven Rostedt wrote:
> You are correct. Now I'm thinking that the WRITE_ONCE() is not needed,
> and just a:
>
> p->mm->numa_scan_seq = READ_ONCE(p->numa_scan_seq) + 1;
Just to confirm, is this a typo? Because there really is a numa_scan_seq
in the
On Wed, 15 Apr 2015 11:49:09 -0700
Jason Low wrote:
> So I'll keep the READ_ONCE nested inside WRITE_ONCE for the purpose of
> this patch since this patch is a conversion from ACCESS_ONCE, but yes,
> if the original purpose of ACCESS_ONCE was to do an atomic increment,
> then the ACCESS_ONCE
On Wed, 2015-04-15 at 09:46 +0200, Ingo Molnar wrote:
> * Steven Rostedt wrote:
> > You are correct. Now I'm thinking that the WRITE_ONCE() is not needed,
> > and just a:
> >
> > p->mm->numa_scan_seq = READ_ONCE(p->numa_scan_seq) + 1;
> >
> > Can be done. But I'm still trying to wrap my
* Steven Rostedt wrote:
> On Tue, 14 Apr 2015 19:12:33 -0700
> Jason Low wrote:
>
> > Hi Steven,
> >
> > On Tue, 2015-04-14 at 19:59 -0400, Steven Rostedt wrote:
> > > On Tue, 14 Apr 2015 16:09:44 -0700
> > > Jason Low wrote:
> > >
> > >
> > > > @@ -2088,7 +2088,7 @@ void
On Wed, 2015-04-15 at 09:46 +0200, Ingo Molnar wrote:
* Steven Rostedt rost...@goodmis.org wrote:
You are correct. Now I'm thinking that the WRITE_ONCE() is not needed,
and just a:
p-mm-numa_scan_seq = READ_ONCE(p-numa_scan_seq) + 1;
Can be done. But I'm still trying to wrap my
On Wed, 15 Apr 2015 11:49:09 -0700
Jason Low jason.l...@hp.com wrote:
So I'll keep the READ_ONCE nested inside WRITE_ONCE for the purpose of
this patch since this patch is a conversion from ACCESS_ONCE, but yes,
if the original purpose of ACCESS_ONCE was to do an atomic increment,
then the
On Tue, 2015-04-14 at 22:40 -0400, Steven Rostedt wrote:
You are correct. Now I'm thinking that the WRITE_ONCE() is not needed,
and just a:
p-mm-numa_scan_seq = READ_ONCE(p-numa_scan_seq) + 1;
Just to confirm, is this a typo? Because there really is a numa_scan_seq
in the task_struct
On Wed, 15 Apr 2015 19:29:01 -0700
Jason Low jason.l...@hp.com wrote:
On Tue, 2015-04-14 at 22:40 -0400, Steven Rostedt wrote:
You are correct. Now I'm thinking that the WRITE_ONCE() is not needed,
and just a:
p-mm-numa_scan_seq = READ_ONCE(p-numa_scan_seq) + 1;
Just to confirm,
Hi Ingo,
On Wed, 2015-04-15 at 09:46 +0200, Ingo Molnar wrote:
* Steven Rostedt rost...@goodmis.org wrote:
You are correct. Now I'm thinking that the WRITE_ONCE() is not needed,
and just a:
p-mm-numa_scan_seq = READ_ONCE(p-numa_scan_seq) + 1;
Can be done. But I'm still trying
* Steven Rostedt rost...@goodmis.org wrote:
On Tue, 14 Apr 2015 19:12:33 -0700
Jason Low jason.l...@hp.com wrote:
Hi Steven,
On Tue, 2015-04-14 at 19:59 -0400, Steven Rostedt wrote:
On Tue, 14 Apr 2015 16:09:44 -0700
Jason Low jason.l...@hp.com wrote:
@@ -2088,7
On Tue, 14 Apr 2015 19:12:33 -0700
Jason Low wrote:
> Hi Steven,
>
> On Tue, 2015-04-14 at 19:59 -0400, Steven Rostedt wrote:
> > On Tue, 14 Apr 2015 16:09:44 -0700
> > Jason Low wrote:
> >
> >
> > > @@ -2088,7 +2088,7 @@ void task_numa_fault(int last_cpupid, int mem_node,
> > > int pages,
Hi Steven,
On Tue, 2015-04-14 at 19:59 -0400, Steven Rostedt wrote:
> On Tue, 14 Apr 2015 16:09:44 -0700
> Jason Low wrote:
>
>
> > @@ -2088,7 +2088,7 @@ void task_numa_fault(int last_cpupid, int mem_node,
> > int pages, int flags)
> >
> > static void reset_ptenuma_scan(struct task_struct
On Tue, 14 Apr 2015 16:09:44 -0700
Jason Low wrote:
> @@ -2088,7 +2088,7 @@ void task_numa_fault(int last_cpupid, int mem_node, int
> pages, int flags)
>
> static void reset_ptenuma_scan(struct task_struct *p)
> {
> - ACCESS_ONCE(p->mm->numa_scan_seq)++;
> +
ACCESS_ONCE doesn't work reliably on non-scalar types. This patch removes
the rest of the existing usages of ACCESS_ONCE in the scheduler, and use
the new READ_ONCE and WRITE_ONCE APIs.
Signed-off-by: Jason Low
---
include/linux/sched.h |4 ++--
kernel/fork.c |
On Tue, 14 Apr 2015 16:09:44 -0700
Jason Low jason.l...@hp.com wrote:
@@ -2088,7 +2088,7 @@ void task_numa_fault(int last_cpupid, int mem_node, int
pages, int flags)
static void reset_ptenuma_scan(struct task_struct *p)
{
- ACCESS_ONCE(p-mm-numa_scan_seq)++;
+
Hi Steven,
On Tue, 2015-04-14 at 19:59 -0400, Steven Rostedt wrote:
On Tue, 14 Apr 2015 16:09:44 -0700
Jason Low jason.l...@hp.com wrote:
@@ -2088,7 +2088,7 @@ void task_numa_fault(int last_cpupid, int mem_node,
int pages, int flags)
static void reset_ptenuma_scan(struct
On Tue, 14 Apr 2015 19:12:33 -0700
Jason Low jason.l...@hp.com wrote:
Hi Steven,
On Tue, 2015-04-14 at 19:59 -0400, Steven Rostedt wrote:
On Tue, 14 Apr 2015 16:09:44 -0700
Jason Low jason.l...@hp.com wrote:
@@ -2088,7 +2088,7 @@ void task_numa_fault(int last_cpupid, int
ACCESS_ONCE doesn't work reliably on non-scalar types. This patch removes
the rest of the existing usages of ACCESS_ONCE in the scheduler, and use
the new READ_ONCE and WRITE_ONCE APIs.
Signed-off-by: Jason Low jason.l...@hp.com
---
include/linux/sched.h |4 ++--
kernel/fork.c
38 matches
Mail list logo
