linux-kernel - Re: [PATCH 07/41] cpuset: Set up interface for nohz flag

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: <alpine.DEB.2.00.1205091001480.10177@router.home>
Date:	Wed, 9 May 2012 10:05:56 -0500 (CDT)
From:	Christoph Lameter <cl@...ux.com>
To:	Mike Galbraith <efault@....de>
cc:	Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	linaro-sched-sig@...ts.linaro.org,
	Alessio Igor Bogani <abogani@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Avi Kivity <avi@...hat.com>,
	Chris Metcalf <cmetcalf@...era.com>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Geoff Levand <geoff@...radead.org>,
	Gilad Ben Yossef <gilad@...yossef.com>,
	Hakan Akkan <hakanakkan@...il.com>,
	Ingo Molnar <mingo@...nel.org>, Kevin Hilman <khilman@...com>,
	Max Krasnyansky <maxk@...lcomm.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Stephen Hemminger <shemminger@...tta.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Sven-Thorsten Dietrich <thebigcorporation@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 07/41] cpuset: Set up interface for nohz flag

On Wed, 9 May 2012, Mike Galbraith wrote:

> On Wed, 2012-05-09 at 09:22 -0500, Christoph Lameter wrote:
> > On Wed, 9 May 2012, Mike Galbraith wrote:
>
> > > > isolcpus are not part of load balancer domains.
> > >
> > > Yup, so if you have an application with an RT component, somewhat
> > > sensitive, needs isolation from rest of a big box, but app also has
> > > SCHED_OTHER components.  isolcpus is a pain, everything has to be static
> > > and nailed to the floor.  Load just works when plugged into a cpuset.
> >
> > Well you have low latency requirements. If you code for lowest latency
> > then you have to consider cache sizes, cache sharing etc etc. This means
> > you will have to nail down everything anyways. Cpusets would just be
> > another thing that one has to worry about.
> >
> > The loads definitely wont work right if just "plugged into a cpuset".
>
> You're talking about serious RT/HPC.  I'm talking about apps/loads with
> modest requirements, like "Please keep that evil nVidia (this that the
> other) thing the _hell_ away from me, I cannot deal with it's futzing
> around in the kernel for a _full second_ at a time".

Well I hope you understand that I do not want to get another complexity
thrown in by having to deal with cpusets too in addition to the pinning,
caches, etc etc.

I do not get how a cpuset could be used by an application with load
balancing disabled. Seems to defeat the purpose of the cpuset (which IMHO
is to generate a custom load balancing domain after all). You would
have to manually pin the processes to processors of the cpuset anyways.

If you already have to pin then why would you want a cpuset on top of
that?


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