All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Low <jason.low2@hp.com>
To: Waiman Long <waiman.long@hp.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Mel Gorman <mgorman@suse.de>, Rik van Riel <riel@redhat.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Preeti U Murthy <preeti@linux.vnet.ibm.com>,
	Mike Galbraith <umgwanakikbuti@gmail.com>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Aswin Chandramouleeswaran <aswin@hp.com>,
	Scott J Norton <scott.norton@hp.com>,
	jason.low2@hp.com
Subject: [PATCH v3 2/5] sched, numa: Document usages of mm->numa_scan_seq
Date: Thu, 30 Apr 2015 17:28:14 -0700	[thread overview]
Message-ID: <1430440094.2475.61.camel@j-VirtualBox> (raw)
In-Reply-To: <1430428387.2475.47.camel@j-VirtualBox>

On Thu, 2015-04-30 at 14:13 -0700, Jason Low wrote:
> On Thu, 2015-04-30 at 14:42 -0400, Waiman Long wrote:
> 
> > I do have a question of what kind of tearing you are talking about. Do 
> > you mean the tearing due to mm being changed in the middle of the 
> > access? The reason why I don't like this kind of construct is that I am 
> > not sure if
> > the address translation p->mm->numa_scan_seq is being done once or 
> > twice. I looked at the compiled code and the translation is done only once.
> > 
> > Anyway, the purpose of READ_ONCE and WRITE_ONCE is not for eliminating 
> > data tearing. They are to make sure that the compiler won't compile away 
> > data access and they are done in the order they appear in the program. I 
> > don't think it is a good idea to associate tearing elimination with 
> > those macros. So I would suggest removing the last sentence in your comment.
> 
> Yes, I can remove the last sentence in the comment since the main goal
> was to document that we're access this field without exclusive access.

---
Subject: [PATCH v3 2/5] sched, numa: Document usages of mm->numa_scan_seq

The p->mm->numa_scan_seq is accessed using READ_ONCE/WRITE_ONCE
and modified without exclusive access. It is not clear why it is
accessed this way. This patch provides some documentation on that.

Signed-off-by: Jason Low <jason.low2@hp.com>
Suggested-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Rik van Riel <riel@redhat.com>
---
 kernel/sched/fair.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 5a44371..65a9a1dc 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1794,6 +1794,11 @@ static void task_numa_placement(struct task_struct *p)
 	u64 runtime, period;
 	spinlock_t *group_lock = NULL;
 
+	/*
+	 * The p->mm->numa_scan_seq gets updated without
+	 * exclusive access. Use READ_ONCE() here to ensure
+	 * that the field is read in a single access.
+	 */
 	seq = READ_ONCE(p->mm->numa_scan_seq);
 	if (p->numa_scan_seq == seq)
 		return;
@@ -2107,6 +2112,14 @@ void task_numa_fault(int last_cpupid, int mem_node, int pages, int flags)
 
 static void reset_ptenuma_scan(struct task_struct *p)
 {
+	/*
+	 * We only did a read acquisition of the mmap sem, so
+	 * p->mm->numa_scan_seq is written to without exclusive access
+	 * and the update is not guaranteed to be atomic. That's not
+	 * much of an issue though, since this is just used for
+	 * statistical sampling. Use READ_ONCE/WRITE_ONCE, which are not
+	 * expensive, to avoid any form of compiler optimizations.
+	 */
 	WRITE_ONCE(p->mm->numa_scan_seq, READ_ONCE(p->mm->numa_scan_seq) + 1);
 	p->mm->numa_scan_offset = 0;
 }
-- 
1.7.2.5




  reply	other threads:[~2015-05-01  0:28 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-28 20:00 [PATCH v2 0/5] sched, timer: Improve scalability of itimers Jason Low
2015-04-28 20:00 ` [PATCH v2 1/5] sched, timer: Remove usages of ACCESS_ONCE in the scheduler Jason Low
2015-04-29 14:34   ` Rik van Riel
2015-04-29 17:05   ` Waiman Long
2015-04-29 17:15     ` Steven Rostedt
2015-04-29 18:25       ` Jason Low
2015-05-08 13:22   ` [tip:sched/core] sched, timer: Convert usages of ACCESS_ONCE() in the scheduler to READ_ONCE()/WRITE_ONCE() tip-bot for Jason Low
2015-04-28 20:00 ` [PATCH v2 2/5] sched, numa: Document usages of mm->numa_scan_seq Jason Low
2015-04-29 14:35   ` Rik van Riel
2015-04-29 18:14   ` Waiman Long
2015-04-29 18:45     ` Jason Low
2015-04-30 18:42       ` Waiman Long
2015-04-30 18:54         ` Davidlohr Bueso
2015-04-30 20:58           ` Waiman Long
2015-04-30 21:26           ` Jason Low
2015-04-30 21:13         ` Jason Low
2015-05-01  0:28           ` Jason Low [this message]
2015-05-08 13:22             ` [tip:sched/core] sched/numa: " tip-bot for Jason Low
2015-05-01 15:21           ` [PATCH v2 2/5] sched, numa: " Paul E. McKenney
2015-05-01 17:40             ` Jason Low
2015-04-28 20:00 ` [PATCH v2 3/5] sched, timer: Use atomics in thread_group_cputimer to improve scalability Jason Low
2015-04-29 14:38   ` Rik van Riel
2015-04-29 20:45     ` Jason Low
2015-04-29 18:43   ` Waiman Long
2015-04-29 20:14     ` Jason Low
2015-05-08 13:22   ` [tip:sched/core] sched, timer: Replace spinlocks with atomics in thread_group_cputimer(), " tip-bot for Jason Low
2015-05-08 21:31     ` [PATCH] sched, timer: Fix documentation for 'struct thread_group_cputimer' Jason Low
2015-05-11  6:41       ` [tip:sched/core] sched, timer: Fix documentation for ' struct thread_group_cputimer' tip-bot for Jason Low
2015-04-28 20:00 ` [PATCH v2 4/5] sched, timer: Provide an atomic task_cputime data structure Jason Low
2015-04-29 14:47   ` Rik van Riel
2015-05-08 13:22   ` [tip:sched/core] sched, timer: Provide an atomic ' struct task_cputime' " tip-bot for Jason Low
2015-04-28 20:00 ` [PATCH v2 5/5] sched, timer: Use the atomic task_cputime in thread_group_cputimer Jason Low
2015-04-29 14:48   ` Rik van Riel
2015-05-08 13:23   ` [tip:sched/core] " tip-bot for Jason Low

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1430440094.2475.61.camel@j-VirtualBox \
    --to=jason.low2@hp.com \
    --cc=akpm@linux-foundation.org \
    --cc=aswin@hp.com \
    --cc=dave@stgolabs.net \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=preeti@linux.vnet.ibm.com \
    --cc=riel@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=scott.norton@hp.com \
    --cc=tglx@linutronix.de \
    --cc=umgwanakikbuti@gmail.com \
    --cc=waiman.long@hp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.