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
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 interface. It addresses all
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
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
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
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 you think. I'll
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
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:
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:
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
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
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
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
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
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 most of what
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
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
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
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
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
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
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
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
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.
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
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
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
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 this
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.
As I
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 really
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
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
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
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
> > > >
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
cgroup solution
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
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
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
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
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
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
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
What
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
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
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 example
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 this
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
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
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 common
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
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
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 = _cpu_data;
+ static struct clos_cbm_map *ccm;
+ u32 maxid, max_cbm_len;
+ size_t sizeb;
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
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
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
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
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 = _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).
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
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
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
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
66 matches
Mail list logo
