linux-kernel - Re: Plumbers: Tweaking scheduler policy micro-conf RFP

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]

Date:	Thu, 17 May 2012 00:19:56 +0530
From:	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Vincent Guittot <vincent.guittot@...aro.org>,
	paulmck@...ux.vnet.ibm.com, smuckle@...cinc.com, khilman@...com,
	Robin.Randhawa@....com, suresh.b.siddha@...el.com,
	thebigcorporation@...il.com, venki@...gle.com,
	panto@...oniou-consulting.com, mingo@...e.hu, paul.brett@...el.com,
	pdeschrijver@...dia.com, pjt@...gle.com, efault@....de,
	fweisbec@...il.com, geoff@...radead.org, rostedt@...dmis.org,
	tglx@...utronix.de, amit.kucheria@...aro.org,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linaro-sched-sig@...ts.linaro.org,
	Morten Rasmussen <Morten.Rasmussen@....com>,
	Juri Lelli <juri.lelli@...il.com>
Subject: Re: Plumbers: Tweaking scheduler policy micro-conf RFP

* Peter Zijlstra <peterz@...radead.org> [2012-05-15 17:35:41]:

> On Tue, 2012-05-15 at 17:05 +0200, Vincent Guittot wrote:
> > On 15 May 2012 15:00, Peter Zijlstra <peterz@...radead.org> wrote:
> > > On Tue, 2012-05-15 at 14:57 +0200, Vincent Guittot wrote:
 
[snip]

> But really short, look at kernel/sched/core.c:default_topology[]
> 
> I'd like to get rid of sd_init_* into a single function like
> sd_numa_init(), this would mean all archs would need to do is provide a
> simple list of ever increasing masks that match their topology.

You are suggesting that the archs will provide sched/core a list of
masks equivalent to the number of sched domain levels that we need to
build.  The SDTL_SHARE_XXX flag will also be passed per mask in order
to decide the SD flags for that domain.

> To aid this we can add some SDTL_flags, initially I was thinking of:
> 
>  SDTL_SHARE_CORE	-- aka SMT
>  SDTL_SHARE_CACHE	-- LLC cache domain (typically multi-core)
>  SDTL_SHARE_MEMORY	-- NUMA-node (typically socket)
> 
> The 'performance' policy is typically to spread over shared resources so
> as to minimize contention on these.
> 
> If you want to add some power we need some extra flags, maybe something
> like:
> 
>  SDTL_SHARE_POWERLINE	-- power domain (typically socket)

Let me take a case of two-socket,quad-core,HT x86 (Nehalem):

SDTL_SHARE_POWERLINE should be passed along with a cpumask that
represents sd_init_CPU or cpu_cpu_mask today.  So the number of
domains we build per-cpu will depend on the topology and the
sched_powersavings settings. 

--Vaidy

--
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/