[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150805122257.GD4332@codeblueprint.co.uk>
Date: Wed, 5 Aug 2015 13:22:57 +0100
From: Matt Fleming <matt@...eblueprint.co.uk>
To: Tejun Heo <tj@...nel.org>
Cc: Vikas Shivappa <vikas.shivappa@...el.com>,
Vikas Shivappa <vikas.shivappa@...ux.intel.com>,
linux-kernel@...r.kernel.org, x86@...nel.org, hpa@...or.com,
tglx@...utronix.de, mingo@...nel.org, peterz@...radead.org,
matt.fleming@...el.com, will.auld@...el.com,
glenn.p.williamson@...el.com, kanaka.d.juvva@...el.com
Subject: Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service
management
On Sun, 02 Aug, at 12:31:57PM, Tejun Heo wrote:
>
> But we're doing it the wrong way around. You can do most of what
> cgroup interface can do with systemcall-like interface with some
> inconvenience. The other way doesn't really work. As I wrote in the
> other reply, cgroups is a horrible programmable interface and we don't
> want individual applications to interact with it directly and CAT's
> use cases most definitely include each application programming its own
> cache mask.
I wager that this assertion is wrong. Having individual applications
program their own cache mask is not going to be the most common
scenario. Only in very specific situations would you trust an
application to do that.
A much more likely use case is having the sysadmin carve up the cache
for a workload which may include multiple, uncooperating applications.
Yes, a programmable interface would be useful, but only for a limited
set of workloads. I don't think it's how most people are going to want
to use this hardware technology.
--
Matt Fleming, Intel Open Source Technology Center
--
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