[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120920182651.GH28934@google.com>
Date: Thu, 20 Sep 2012 11:26:51 -0700
From: Tejun Heo <tj@...nel.org>
To: Andy Lutomirski <luto@...capital.net>
Cc: containers@...ts.linux-foundation.org, cgroups@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Neil Horman <nhorman@...driver.org>,
Michal Hocko <mhocko@...e.cz>,
Paul Mackerras <paulus@...ba.org>,
"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
Johannes Weiner <hannes@...xchg.org>,
Thomas Graf <tgraf@...g.ch>, Paul Turner <pjt@...gle.com>,
Ingo Molnar <mingo@...e.hu>, serge.hallyn@...onical.com
Subject: Re: [RFC] cgroup TODOs
Hello,
On Wed, Sep 19, 2012 at 06:33:15PM -0700, Andy Lutomirski wrote:
> [grr. why does gmane scramble addresses?]
You can append /raw to the message url and see the raw mssage.
http://article.gmane.org/gmane.linux.kernel.containers/23802/raw
> > I think this level of flexibility should be enough for most use
> > cases. If someone disagrees, please voice your objections now.
>
> OK, I'll bite.
>
> I have a server that has a whole bunch of cores. A small fraction of
> those cores are general purpose and run whatever they like. The rest
> are tightly controlled.
>
> For simplicity, we have two cpusets that we use. The root allows all
> cpus. The other one only allows the general purpose cpus. We shove
> everything into the general-purpose-only cpuset, and then we move
> special stuff back to root. (We also shove some kernel threads into a
> non-root cpuset using the 'cset' tool.)
Using root for special stuff probably isn't a good idea and moving
bound kthreads into !root cgroups is already disallowed.
> Enter systemd, which wants a hierarchy corresponding to services. If we
> were to use it, we might end up violating its hierarchy.
>
> Alternatively, if we started using memcg, then we might have some tasks
> to have more restrictive memory usage but less restrictive cpu usage.
>
> As long as we can still pull this off, I'm happy.
IIUC, you basically want just two groups w/ cpuset and use it for
loose cpu ioslation for high priority jobs. Structure-wise, I don't
think it's gonna be a problem although using root for special stuff
would need to change.
Thanks.
--
tejun
--
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/
Powered by blists - more mailing lists