linux-kernel - Re: [PATCH 3/8] sched: Select a preferred node with the most numa hinting faults

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130628123300.GU1875@suse.de>
Date:	Fri, 28 Jun 2013 13:33:00 +0100
From:	Mel Gorman <mgorman@...e.de>
To:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...nel.org>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Linux-MM <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/8] sched: Select a preferred node with the most numa
 hinting faults

On Fri, Jun 28, 2013 at 11:44:28AM +0530, Srikar Dronamraju wrote:
> * Mel Gorman <mgorman@...e.de> [2013-06-26 15:38:02]:
> 
> > This patch selects a preferred node for a task to run on based on the
> > NUMA hinting faults. This information is later used to migrate tasks
> > towards the node during balancing.
> > 
> > Signed-off-by: Mel Gorman <mgorman@...e.de>
> > ---
> >  include/linux/sched.h |  1 +
> >  kernel/sched/core.c   | 10 ++++++++++
> >  kernel/sched/fair.c   | 16 ++++++++++++++--
> >  kernel/sched/sched.h  |  2 +-
> >  4 files changed, 26 insertions(+), 3 deletions(-)
> > 
> > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > index 72861b4..ba46a64 100644
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -1507,6 +1507,7 @@ struct task_struct {
> >  	struct callback_head numa_work;
> >  
> >  	unsigned long *numa_faults;
> > +	int numa_preferred_nid;
> >  #endif /* CONFIG_NUMA_BALANCING */
> >  
> >  	struct rcu_head rcu;
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index f332ec0..019baae 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -1593,6 +1593,7 @@ static void __sched_fork(struct task_struct *p)
> >  	p->numa_scan_seq = p->mm ? p->mm->numa_scan_seq : 0;
> >  	p->numa_migrate_seq = p->mm ? p->mm->numa_scan_seq - 1 : 0;
> >  	p->numa_scan_period = sysctl_numa_balancing_scan_delay;
> > +	p->numa_preferred_nid = -1;
> 
> Though we may not want to inherit faults, I think the tasks generally
> share pages with their siblings, parent. So will it make sense to
> inherit the preferred node?
> 

If it really shared data with its parent then it will be detected by the PTE
scanner later as normal. I would expect that initially it would be scheduled
to run on CPUs on the local node and I would think that inheriting it here
will not make a detectable difference. If you think it will, I can do it
but then the data should certainly be cleared on exec.

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/