[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1710301045160.970@nuc-kabylake>
Date: Mon, 30 Oct 2017 10:48:04 -0500 (CDT)
From: Christopher Lameter <cl@...ux.com>
To: Peter Zijlstra <peterz@...radead.org>
cc: cmetcalf@...lanox.com, linux-kernel@...r.kernel.org,
tglx@...utronix.de, torvalds@...ux-foundation.org, hpa@...or.com,
riel@...hat.com, mingo@...nel.org, efault@....de,
frederic@...nel.org, kernellwp@...il.com,
paulmck@...ux.vnet.ibm.com, lcapitulino@...hat.com,
linux-tip-commits@...r.kernel.org
Subject: Re: [tip:sched/core] sched/isolation: Document the isolcpus= flags
On Fri, 27 Oct 2017, Peter Zijlstra wrote:
> I _strongly_ object to this statement, isolcpus is _not_ the preferred
> way, cpusets are.
>
> And yes, while cpusets suffers some problems, we _should_ really fix
> those and not promote this piece of shit isolcpus crap.
Well low level control at the processor level is important and this allows
controlling activities on a processor that is supposed to be dedicated to
certain activities without OS interaction.
isolcpus is the *right* approach here because you are micromanaging the OS
and are putting dedicated pieces of software on each core.
A cgroup suggests that threads would be scheduled over multiple cores
which is *not* what you want. cgroup has to do something with containers
etc which is inherently more noisy and needed if you want to do different
things with your processing resources.
Powered by blists - more mailing lists