On Sun, Aug 23, 2015 at 11:47:49AM -0700, Vikas Shivappa wrote:
>
>
> On Fri, 21 Aug 2015, Marcelo Tosatti wrote:
>
> >On Thu, Aug 20, 2015 at 05:06:51PM -0700, Vikas Shivappa wrote:
> >>
> >>
> >>On Mon, 17 Aug 2015, Marcelo Tosatti wrote:
> >>
> >>>Vikas, Tejun,
> >>>
> >>>This is an updated i
On Fri, 21 Aug 2015, Marcelo Tosatti wrote:
On Thu, Aug 20, 2015 at 05:06:51PM -0700, Vikas Shivappa wrote:
On Mon, 17 Aug 2015, Marcelo Tosatti wrote:
Vikas, Tejun,
This is an updated interface. It addresses all comments made
so far and also covers all use-cases the cgroup interface
cov
On Thu, Aug 20, 2015 at 05:06:51PM -0700, Vikas Shivappa wrote:
>
>
> On Mon, 17 Aug 2015, Marcelo Tosatti wrote:
>
> >Vikas, Tejun,
> >
> >This is an updated interface. It addresses all comments made
> >so far and also covers all use-cases the cgroup interface
> >covers.
> >
> >Let me know what
On Thu, 20 Aug 2015, Vikas Shivappa wrote:
On Mon, 17 Aug 2015, Marcelo Tosatti wrote:
Vikas, Tejun,
This is an updated interface. It addresses all comments made
so far and also covers all use-cases the cgroup interface
covers.
Let me know what you think. I'll proceed to writing
the test
On Mon, 17 Aug 2015, Marcelo Tosatti wrote:
Vikas, Tejun,
This is an updated interface. It addresses all comments made
so far and also covers all use-cases the cgroup interface
covers.
Let me know what you think. I'll proceed to writing
the test applications.
Usage model:
This
Vikas, Tejun,
This is an updated interface. It addresses all comments made
so far and also covers all use-cases the cgroup interface
covers.
Let me know what you think. I'll proceed to writing
the test applications.
Usage model:
This document details how CAT technology is
expose
Hello,
On Thu, Aug 06, 2015 at 01:58:39PM -0700, Vikas Shivappa wrote:
> >I'm having hard time believing that. There definitely are use cases
> >where cachelines are trashed among service threads. Are you
> >proclaiming that those cases aren't gonna be supported?
>
> Please refer to the noisy n
On Thu, Aug 06, 2015 at 01:46:06PM -0700, Vikas Shivappa wrote:
>
>
> On Wed, 5 Aug 2015, Marcelo Tosatti wrote:
>
> >On Wed, Aug 05, 2015 at 01:22:57PM +0100, Matt Fleming wrote:
> >>On Sun, 02 Aug, at 12:31:57PM, Tejun Heo wrote:
> >>>
> >>>But we're doing it the wrong way around. You can do
This patch adds a cgroup subsystem for Intel Resource Director
Technology (RDT) feature. This cgroup may eventually be used by many
sub-features of RDT. Therefore the cgroup may be associated with the
common RDT framework as well as sub-feature specific framework. Patch
also adds Class of service i
On Wed, 5 Aug 2015, Tejun Heo wrote:
Hello,
On Tue, Aug 04, 2015 at 07:21:52PM -0700, Vikas Shivappa wrote:
I get that this would be an easier "bolt-on" solution but isn't a good
solution by itself in the long term. As I wrote multiple times
before, this is a really bad programmable interfa
On Wed, 5 Aug 2015, Marcelo Tosatti wrote:
On Wed, Aug 05, 2015 at 01:22:57PM +0100, Matt Fleming wrote:
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
inconve
On Wed, Aug 05, 2015 at 01:22:57PM +0100, Matt Fleming wrote:
> 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 r
Hello,
On Wed, Aug 05, 2015 at 01:22:57PM +0100, Matt Fleming wrote:
> 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
Hello,
On Tue, Aug 04, 2015 at 07:21:52PM -0700, Vikas Shivappa wrote:
> >I get that this would be an easier "bolt-on" solution but isn't a good
> >solution by itself in the long term. As I wrote multiple times
> >before, this is a really bad programmable interface. Unless you're
> >sure that th
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 prog
On Tue, 4 Aug 2015, Tejun Heo wrote:
Hello, Vikas.
On Tue, Aug 04, 2015 at 11:50:16AM -0700, Vikas Shivappa wrote:
I will make this more clear in the documentation - We intend this cgroup
interface to be used by a root or superuser - more like a system
administrator being able to control the
Hello, Vikas.
On Tue, Aug 04, 2015 at 11:50:16AM -0700, Vikas Shivappa wrote:
> I will make this more clear in the documentation - We intend this cgroup
> interface to be used by a root or superuser - more like a system
> administrator being able to control the allocation of the threads , the one
Hello,
On Tue, Aug 04, 2015 at 09:55:20AM -0300, Marcelo Tosatti wrote:
...
> Can't "cacheset" helper (similar to taskset) talk to systemd
> to achieve the flexibility you point ?
I don't know. This is the case in point. You're now suggesting doing
things completely backwards - a thread of an a
Hello Tejun,
On Sun, 2 Aug 2015, Tejun Heo wrote:
Hello, Vikas.
On Fri, Jul 31, 2015 at 09:24:58AM -0700, Vikas Shivappa wrote:
Yes today we dont have an alternative interface - but we can always build
one. We simply dont have it because till now Linux kernel just tolerated the
degradation t
Hello,
On Mon, Aug 03, 2015 at 05:32:50PM -0300, Marcelo Tosatti wrote:
> You really want to specify the cache configuration "at once":
> having process-A exclusive access to 2MB of cache at all times,
> and process-B 4MB exclusive, means you can't have process-C use 4MB of
> cache exclusively (
On Mon, Aug 03, 2015 at 05:32:50PM -0300, Marcelo Tosatti wrote:
> On Sun, Aug 02, 2015 at 12:23:25PM -0400, Tejun Heo wrote:
> > Hello,
> >
> > On Fri, Jul 31, 2015 at 12:12:18PM -0300, Marcelo Tosatti wrote:
> > > > I don't really think it makes sense to implement a fully hierarchical
> > > > cg
On Sun, Aug 02, 2015 at 12:23:25PM -0400, Tejun Heo wrote:
> Hello,
>
> On Fri, Jul 31, 2015 at 12:12:18PM -0300, Marcelo Tosatti wrote:
> > > I don't really think it makes sense to implement a fully hierarchical
> > > cgroup solution when there isn't the basic affinity-adjusting
> > > interface
Hello, Vikas.
On Fri, Jul 31, 2015 at 09:24:58AM -0700, Vikas Shivappa wrote:
> Yes today we dont have an alternative interface - but we can always build
> one. We simply dont have it because till now Linux kernel just tolerated the
> degradation that could have occured by cache contention and thi
Hello,
On Fri, Jul 31, 2015 at 12:12:18PM -0300, Marcelo Tosatti wrote:
> > I don't really think it makes sense to implement a fully hierarchical
> > cgroup solution when there isn't the basic affinity-adjusting
> > interface
>
> What is an "affinity adjusting interface" ? Can you give an exampl
On Thu, 30 Jul 2015, Tejun Heo wrote:
Hello, Vikas.
On Wed, Jul 01, 2015 at 03:21:06PM -0700, Vikas Shivappa wrote:
This patch adds a cgroup subsystem for Intel Resource Director
Technology(RDT) feature and Class of service(CLOSid) management which is
part of common RDT framework. This cgro
On Thu, Jul 30, 2015 at 03:44:58PM -0400, Tejun Heo wrote:
> Hello, Vikas.
>
> On Wed, Jul 01, 2015 at 03:21:06PM -0700, Vikas Shivappa wrote:
> > This patch adds a cgroup subsystem for Intel Resource Director
> > Technology(RDT) feature and Class of service(CLOSid) management which is
> > part of
Hello, Vikas.
On Wed, Jul 01, 2015 at 03:21:06PM -0700, Vikas Shivappa wrote:
> This patch adds a cgroup subsystem for Intel Resource Director
> Technology(RDT) feature and Class of service(CLOSid) management which is
> part of common RDT framework. This cgroup would eventually be used by
> all s
On Tue, 28 Jul 2015, Peter Zijlstra wrote:
On Wed, Jul 01, 2015 at 03:21:06PM -0700, Vikas Shivappa wrote:
static int __init intel_rdt_late_init(void)
{
struct cpuinfo_x86 *c = &boot_cpu_data;
+ static struct clos_cbm_map *ccm;
+ u32 maxid, max_cbm_len;
+ size_t si
On Tue, 28 Jul 2015, Peter Zijlstra wrote:
On Wed, Jul 01, 2015 at 03:21:06PM -0700, Vikas Shivappa wrote:
+struct clos_cbm_map {
+ unsigned long cache_mask;
+ unsigned int clos_refcnt;
+};
This structure is not a map at all, its the map value. Furthermore,
cache_mask seems a co
On Wed, Jul 01, 2015 at 03:21:06PM -0700, Vikas Shivappa wrote:
> static int __init intel_rdt_late_init(void)
> {
> struct cpuinfo_x86 *c = &boot_cpu_data;
> + static struct clos_cbm_map *ccm;
> + u32 maxid, max_cbm_len;
> + size_t sizeb;
Why 'sizeb' ? 'size' is still available
On Wed, Jul 01, 2015 at 03:21:06PM -0700, Vikas Shivappa wrote:
> +struct clos_cbm_map {
> + unsigned long cache_mask;
> + unsigned int clos_refcnt;
> +};
This structure is not a map at all, its the map value. Furthermore,
cache_mask seems a confusing name for the capacity bitmask (CBM).
-
This patch adds a cgroup subsystem for Intel Resource Director
Technology(RDT) feature and Class of service(CLOSid) management which is
part of common RDT framework. This cgroup would eventually be used by
all sub-features of RDT and hence be associated with the common RDT
framework as well as sub
This patch adds a cgroup subsystem for Intel Resource Director
Technology(RDT) feature and Class of service(CLOSid) management which is
part of common RDT framework. This cgroup would eventually be used by
all sub-features of RDT and hence be associated with the common RDT
framework as well as sub
33 matches
Mail list logo
