Re: [PATCH V16 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation

[Richard Weinberger]

Am 04.01.2016 um 22:44 schrieb Yu, Fenghua:
>> From: Richard Weinberger [mailto:richard.weinber...@gmail.com]
>> Sent: Saturday, January 02, 2016 2:54 PM
>> On Mon, Dec 21, 2015 at 6:05 PM, Marcelo Tosatti 
>> wrote:
>>> OK cool hopefully that makes it clear to Fenghua Yu what must be
>>> changed in the patchset.
>>>
  - http://lkml.iu.edu/hypermail/linux/kernel/1511.0/02375.html
>>
>> ...beating a dead horse but this patch is in -next and breaks the ARCH=um
>> build when enabled.
>>
>>   UPD include/generated/compile.h
>>   CC  init/version.o
>>   LD  init/built-in.o
>> kernel/built-in.o:(.rodata+0x2920): undefined reference to
>> `intel_rdt_cgrp_subsys'
>> collect2: error: ld returned 1 exit status
>> make: *** [vmlinux] Error 1
> 
> Do you set CONFIG_INTEL_RDT=y?

Yes. My build bot does allyesconfig builds. :)
IIUC the driver does not make sense for UML, does it?

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH V16 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation

[Yu, Fenghua]

> From: Richard Weinberger [mailto:richard.weinber...@gmail.com]
> Sent: Saturday, January 02, 2016 2:54 PM
> On Mon, Dec 21, 2015 at 6:05 PM, Marcelo Tosatti 
> wrote:
> > OK cool hopefully that makes it clear to Fenghua Yu what must be
> > changed in the patchset.
> >
> >>  - http://lkml.iu.edu/hypermail/linux/kernel/1511.0/02375.html
> 
> ...beating a dead horse but this patch is in -next and breaks the ARCH=um
> build when enabled.
> 
>   UPD include/generated/compile.h
>   CC  init/version.o
>   LD  init/built-in.o
> kernel/built-in.o:(.rodata+0x2920): undefined reference to
> `intel_rdt_cgrp_subsys'
> collect2: error: ld returned 1 exit status
> make: *** [vmlinux] Error 1

Do you set CONFIG_INTEL_RDT=y?

Thanks.

-Fenghua

Re: [PATCH V16 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation

[Richard Weinberger]

Am 04.01.2016 um 22:44 schrieb Yu, Fenghua:
>> From: Richard Weinberger [mailto:richard.weinber...@gmail.com]
>> Sent: Saturday, January 02, 2016 2:54 PM
>> On Mon, Dec 21, 2015 at 6:05 PM, Marcelo Tosatti 
>> wrote:
>>> OK cool hopefully that makes it clear to Fenghua Yu what must be
>>> changed in the patchset.
>>>
  - http://lkml.iu.edu/hypermail/linux/kernel/1511.0/02375.html
>>
>> ...beating a dead horse but this patch is in -next and breaks the ARCH=um
>> build when enabled.
>>
>>   UPD include/generated/compile.h
>>   CC  init/version.o
>>   LD  init/built-in.o
>> kernel/built-in.o:(.rodata+0x2920): undefined reference to
>> `intel_rdt_cgrp_subsys'
>> collect2: error: ld returned 1 exit status
>> make: *** [vmlinux] Error 1
> 
> Do you set CONFIG_INTEL_RDT=y?

Yes. My build bot does allyesconfig builds. :)
IIUC the driver does not make sense for UML, does it?

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH V16 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation

[Yu, Fenghua]

> From: Richard Weinberger [mailto:richard.weinber...@gmail.com]
> Sent: Saturday, January 02, 2016 2:54 PM
> On Mon, Dec 21, 2015 at 6:05 PM, Marcelo Tosatti 
> wrote:
> > OK cool hopefully that makes it clear to Fenghua Yu what must be
> > changed in the patchset.
> >
> >>  - http://lkml.iu.edu/hypermail/linux/kernel/1511.0/02375.html
> 
> ...beating a dead horse but this patch is in -next and breaks the ARCH=um
> build when enabled.
> 
>   UPD include/generated/compile.h
>   CC  init/version.o
>   LD  init/built-in.o
> kernel/built-in.o:(.rodata+0x2920): undefined reference to
> `intel_rdt_cgrp_subsys'
> collect2: error: ld returned 1 exit status
> make: *** [vmlinux] Error 1

Do you set CONFIG_INTEL_RDT=y?

Thanks.

-Fenghua

Re: [PATCH V16 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation

[Richard Weinberger]

On Mon, Dec 21, 2015 at 6:05 PM, Marcelo Tosatti  wrote:
> OK cool hopefully that makes it clear to Fenghua Yu what must
> be changed in the patchset.
>
>>  - http://lkml.iu.edu/hypermail/linux/kernel/1511.0/02375.html

...beating a dead horse but this patch is in -next and breaks the
ARCH=um build when enabled.

  UPD include/generated/compile.h
  CC  init/version.o
  LD  init/built-in.o
kernel/built-in.o:(.rodata+0x2920): undefined reference to
`intel_rdt_cgrp_subsys'
collect2: error: ld returned 1 exit status
make: *** [vmlinux] Error 1

-- 
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V16 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation

[Richard Weinberger]

On Mon, Dec 21, 2015 at 6:05 PM, Marcelo Tosatti  wrote:
> OK cool hopefully that makes it clear to Fenghua Yu what must
> be changed in the patchset.
>
>>  - http://lkml.iu.edu/hypermail/linux/kernel/1511.0/02375.html

...beating a dead horse but this patch is in -next and breaks the
ARCH=um build when enabled.

  UPD include/generated/compile.h
  CC  init/version.o
  LD  init/built-in.o
kernel/built-in.o:(.rodata+0x2920): undefined reference to
`intel_rdt_cgrp_subsys'
collect2: error: ld returned 1 exit status
make: *** [vmlinux] Error 1

-- 
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V16 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation

[Marcelo Tosatti]

On Mon, Dec 21, 2015 at 10:48:22AM -0500, Luiz Capitulino wrote:
> On Sat, 19 Dec 2015 22:57:30 -0200
> Marcelo Tosatti  wrote:
> 
> > On Sat, Dec 19, 2015 at 11:42:57AM +0100, Thomas Gleixner wrote:
> > > On Thu, 17 Dec 2015, Fenghua Yu wrote:
> > > 
> > > > From: Fenghua Yu 
> > > > 
> > > > From: Vikas Shivappa 
> > > > 
> > > > Add a new cgroup 'intel_rdt' to manage cache allocation. Each cgroup
> > > > directory is associated with a class of service id(closid). To map a
> > > > task with closid during scheduling, this patch removes the closid field
> > > > from task_struct and uses the already existing 'cgroups' field in
> > > > task_struct.
> > > > 
> > > > The cgroup has a file 'l3_cbm' which represents the L3 cache capacity
> > > > bitmask(CBM). The CBM is global for the whole system currently. The
> > > > capacity bitmask needs to have only contiguous bits set and number of
> > > > bits that can be set is less than the max bits that can be set. The
> > > > tasks belonging to a cgroup get to fill in the L3 cache represented by
> > > > the capacity bitmask of the cgroup. For ex: if the max bits in the CBM
> > > > is 10 and the cache size is 10MB, each bit represents 1MB of cache
> > > > capacity.
> > > > 
> > > > Root cgroup always has all the bits set in the l3_cbm. User can create
> > > > more cgroups with mkdir syscall. By default the child cgroups inherit
> > > > the capacity bitmask(CBM) from parent. User can change the CBM specified
> > > > in hex for each cgroup. Each unique bitmask is associated with a class
> > > > of service ID and an -ENOSPC is returned once we run out of
> > > > closids.
> > > 
> > > This is still the original crap. No, we are not introducing this
> > > interface now just because we can. I explained in great length why
> > > this is completely useless and what we really need.
> > > 
> > > Thanks,
> > > 
> > >   tglx
> > 
> > Can you make a summary of the points, and enumerate them, please.
> > (what are the problems of the current interface, and why such problems
> > are fixed in the new interface?).
> 
> Marcelo, you participated on the discussions. We discussed why this
> is a bad interface a *lot* in the v15 posting. There are two writeups
> that summarize all the problems:
> 
>  - https://lkml.org/lkml/2015/11/18/637

OK cool hopefully that makes it clear to Fenghua Yu what must
be changed in the patchset.

>  - http://lkml.iu.edu/hypermail/linux/kernel/1511.0/02375.html

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V16 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation

[Luiz Capitulino]

On Sat, 19 Dec 2015 22:57:30 -0200
Marcelo Tosatti  wrote:

> On Sat, Dec 19, 2015 at 11:42:57AM +0100, Thomas Gleixner wrote:
> > On Thu, 17 Dec 2015, Fenghua Yu wrote:
> > 
> > > From: Fenghua Yu 
> > > 
> > > From: Vikas Shivappa 
> > > 
> > > Add a new cgroup 'intel_rdt' to manage cache allocation. Each cgroup
> > > directory is associated with a class of service id(closid). To map a
> > > task with closid during scheduling, this patch removes the closid field
> > > from task_struct and uses the already existing 'cgroups' field in
> > > task_struct.
> > > 
> > > The cgroup has a file 'l3_cbm' which represents the L3 cache capacity
> > > bitmask(CBM). The CBM is global for the whole system currently. The
> > > capacity bitmask needs to have only contiguous bits set and number of
> > > bits that can be set is less than the max bits that can be set. The
> > > tasks belonging to a cgroup get to fill in the L3 cache represented by
> > > the capacity bitmask of the cgroup. For ex: if the max bits in the CBM
> > > is 10 and the cache size is 10MB, each bit represents 1MB of cache
> > > capacity.
> > > 
> > > Root cgroup always has all the bits set in the l3_cbm. User can create
> > > more cgroups with mkdir syscall. By default the child cgroups inherit
> > > the capacity bitmask(CBM) from parent. User can change the CBM specified
> > > in hex for each cgroup. Each unique bitmask is associated with a class
> > > of service ID and an -ENOSPC is returned once we run out of
> > > closids.
> > 
> > This is still the original crap. No, we are not introducing this
> > interface now just because we can. I explained in great length why
> > this is completely useless and what we really need.
> > 
> > Thanks,
> > 
> > tglx
> 
> Can you make a summary of the points, and enumerate them, please.
> (what are the problems of the current interface, and why such problems
> are fixed in the new interface?).

Marcelo, you participated on the discussions. We discussed why this
is a bad interface a *lot* in the v15 posting. There are two writeups
that summarize all the problems:

 - https://lkml.org/lkml/2015/11/18/637

 - http://lkml.iu.edu/hypermail/linux/kernel/1511.0/02375.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V16 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation

[Thomas Gleixner]

On Sat, 19 Dec 2015, Marcelo Tosatti wrote:
> On Sat, Dec 19, 2015 at 11:42:57AM +0100, Thomas Gleixner wrote:
> > This is still the original crap. No, we are not introducing this
> > interface now just because we can. I explained in great length why
> > this is completely useless and what we really need.
> > 
> > Thanks,
> > 
> > tglx
> 
> Can you make a summary of the points, and enumerate them, please.
> (what are the problems of the current interface, and why such problems
> are fixed in the new interface?).
> 
> Then someone can write it, integrate it, and everyone is happy.

LMGTFY: http://bfy.tw/3NzC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V16 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation

[Marcelo Tosatti]

On Sat, Dec 19, 2015 at 11:42:57AM +0100, Thomas Gleixner wrote:
> On Thu, 17 Dec 2015, Fenghua Yu wrote:
> 
> > From: Fenghua Yu 
> > 
> > From: Vikas Shivappa 
> > 
> > Add a new cgroup 'intel_rdt' to manage cache allocation. Each cgroup
> > directory is associated with a class of service id(closid). To map a
> > task with closid during scheduling, this patch removes the closid field
> > from task_struct and uses the already existing 'cgroups' field in
> > task_struct.
> > 
> > The cgroup has a file 'l3_cbm' which represents the L3 cache capacity
> > bitmask(CBM). The CBM is global for the whole system currently. The
> > capacity bitmask needs to have only contiguous bits set and number of
> > bits that can be set is less than the max bits that can be set. The
> > tasks belonging to a cgroup get to fill in the L3 cache represented by
> > the capacity bitmask of the cgroup. For ex: if the max bits in the CBM
> > is 10 and the cache size is 10MB, each bit represents 1MB of cache
> > capacity.
> > 
> > Root cgroup always has all the bits set in the l3_cbm. User can create
> > more cgroups with mkdir syscall. By default the child cgroups inherit
> > the capacity bitmask(CBM) from parent. User can change the CBM specified
> > in hex for each cgroup. Each unique bitmask is associated with a class
> > of service ID and an -ENOSPC is returned once we run out of
> > closids.
> 
> This is still the original crap. No, we are not introducing this
> interface now just because we can. I explained in great length why
> this is completely useless and what we really need.
> 
> Thanks,
> 
>   tglx

Can you make a summary of the points, and enumerate them, please.
(what are the problems of the current interface, and why such problems
are fixed in the new interface?).

Then someone can write it, integrate it, and everyone is happy.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V16 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation

[Marcelo Tosatti]

On Mon, Dec 21, 2015 at 10:48:22AM -0500, Luiz Capitulino wrote:
> On Sat, 19 Dec 2015 22:57:30 -0200
> Marcelo Tosatti  wrote:
> 
> > On Sat, Dec 19, 2015 at 11:42:57AM +0100, Thomas Gleixner wrote:
> > > On Thu, 17 Dec 2015, Fenghua Yu wrote:
> > > 
> > > > From: Fenghua Yu 
> > > > 
> > > > From: Vikas Shivappa 
> > > > 
> > > > Add a new cgroup 'intel_rdt' to manage cache allocation. Each cgroup
> > > > directory is associated with a class of service id(closid). To map a
> > > > task with closid during scheduling, this patch removes the closid field
> > > > from task_struct and uses the already existing 'cgroups' field in
> > > > task_struct.
> > > > 
> > > > The cgroup has a file 'l3_cbm' which represents the L3 cache capacity
> > > > bitmask(CBM). The CBM is global for the whole system currently. The
> > > > capacity bitmask needs to have only contiguous bits set and number of
> > > > bits that can be set is less than the max bits that can be set. The
> > > > tasks belonging to a cgroup get to fill in the L3 cache represented by
> > > > the capacity bitmask of the cgroup. For ex: if the max bits in the CBM
> > > > is 10 and the cache size is 10MB, each bit represents 1MB of cache
> > > > capacity.
> > > > 
> > > > Root cgroup always has all the bits set in the l3_cbm. User can create
> > > > more cgroups with mkdir syscall. By default the child cgroups inherit
> > > > the capacity bitmask(CBM) from parent. User can change the CBM specified
> > > > in hex for each cgroup. Each unique bitmask is associated with a class
> > > > of service ID and an -ENOSPC is returned once we run out of
> > > > closids.
> > > 
> > > This is still the original crap. No, we are not introducing this
> > > interface now just because we can. I explained in great length why
> > > this is completely useless and what we really need.
> > > 
> > > Thanks,
> > > 
> > >   tglx
> > 
> > Can you make a summary of the points, and enumerate them, please.
> > (what are the problems of the current interface, and why such problems
> > are fixed in the new interface?).
> 
> Marcelo, you participated on the discussions. We discussed why this
> is a bad interface a *lot* in the v15 posting. There are two writeups
> that summarize all the problems:
> 
>  - https://lkml.org/lkml/2015/11/18/637

OK cool hopefully that makes it clear to Fenghua Yu what must
be changed in the patchset.

>  - http://lkml.iu.edu/hypermail/linux/kernel/1511.0/02375.html

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V16 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation

[Thomas Gleixner]

On Sat, 19 Dec 2015, Marcelo Tosatti wrote:
> On Sat, Dec 19, 2015 at 11:42:57AM +0100, Thomas Gleixner wrote:
> > This is still the original crap. No, we are not introducing this
> > interface now just because we can. I explained in great length why
> > this is completely useless and what we really need.
> > 
> > Thanks,
> > 
> > tglx
> 
> Can you make a summary of the points, and enumerate them, please.
> (what are the problems of the current interface, and why such problems
> are fixed in the new interface?).
> 
> Then someone can write it, integrate it, and everyone is happy.

LMGTFY: http://bfy.tw/3NzC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V16 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation

[Marcelo Tosatti]

On Sat, Dec 19, 2015 at 11:42:57AM +0100, Thomas Gleixner wrote:
> On Thu, 17 Dec 2015, Fenghua Yu wrote:
> 
> > From: Fenghua Yu 
> > 
> > From: Vikas Shivappa 
> > 
> > Add a new cgroup 'intel_rdt' to manage cache allocation. Each cgroup
> > directory is associated with a class of service id(closid). To map a
> > task with closid during scheduling, this patch removes the closid field
> > from task_struct and uses the already existing 'cgroups' field in
> > task_struct.
> > 
> > The cgroup has a file 'l3_cbm' which represents the L3 cache capacity
> > bitmask(CBM). The CBM is global for the whole system currently. The
> > capacity bitmask needs to have only contiguous bits set and number of
> > bits that can be set is less than the max bits that can be set. The
> > tasks belonging to a cgroup get to fill in the L3 cache represented by
> > the capacity bitmask of the cgroup. For ex: if the max bits in the CBM
> > is 10 and the cache size is 10MB, each bit represents 1MB of cache
> > capacity.
> > 
> > Root cgroup always has all the bits set in the l3_cbm. User can create
> > more cgroups with mkdir syscall. By default the child cgroups inherit
> > the capacity bitmask(CBM) from parent. User can change the CBM specified
> > in hex for each cgroup. Each unique bitmask is associated with a class
> > of service ID and an -ENOSPC is returned once we run out of
> > closids.
> 
> This is still the original crap. No, we are not introducing this
> interface now just because we can. I explained in great length why
> this is completely useless and what we really need.
> 
> Thanks,
> 
>   tglx

Can you make a summary of the points, and enumerate them, please.
(what are the problems of the current interface, and why such problems
are fixed in the new interface?).

Then someone can write it, integrate it, and everyone is happy.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V16 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation

[Luiz Capitulino]

On Sat, 19 Dec 2015 22:57:30 -0200
Marcelo Tosatti  wrote:

> On Sat, Dec 19, 2015 at 11:42:57AM +0100, Thomas Gleixner wrote:
> > On Thu, 17 Dec 2015, Fenghua Yu wrote:
> > 
> > > From: Fenghua Yu 
> > > 
> > > From: Vikas Shivappa 
> > > 
> > > Add a new cgroup 'intel_rdt' to manage cache allocation. Each cgroup
> > > directory is associated with a class of service id(closid). To map a
> > > task with closid during scheduling, this patch removes the closid field
> > > from task_struct and uses the already existing 'cgroups' field in
> > > task_struct.
> > > 
> > > The cgroup has a file 'l3_cbm' which represents the L3 cache capacity
> > > bitmask(CBM). The CBM is global for the whole system currently. The
> > > capacity bitmask needs to have only contiguous bits set and number of
> > > bits that can be set is less than the max bits that can be set. The
> > > tasks belonging to a cgroup get to fill in the L3 cache represented by
> > > the capacity bitmask of the cgroup. For ex: if the max bits in the CBM
> > > is 10 and the cache size is 10MB, each bit represents 1MB of cache
> > > capacity.
> > > 
> > > Root cgroup always has all the bits set in the l3_cbm. User can create
> > > more cgroups with mkdir syscall. By default the child cgroups inherit
> > > the capacity bitmask(CBM) from parent. User can change the CBM specified
> > > in hex for each cgroup. Each unique bitmask is associated with a class
> > > of service ID and an -ENOSPC is returned once we run out of
> > > closids.
> > 
> > This is still the original crap. No, we are not introducing this
> > interface now just because we can. I explained in great length why
> > this is completely useless and what we really need.
> > 
> > Thanks,
> > 
> > tglx
> 
> Can you make a summary of the points, and enumerate them, please.
> (what are the problems of the current interface, and why such problems
> are fixed in the new interface?).

Marcelo, you participated on the discussions. We discussed why this
is a bad interface a *lot* in the v15 posting. There are two writeups
that summarize all the problems:

 - https://lkml.org/lkml/2015/11/18/637

 - http://lkml.iu.edu/hypermail/linux/kernel/1511.0/02375.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V16 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation

[Thomas Gleixner]

On Thu, 17 Dec 2015, Fenghua Yu wrote:

> From: Fenghua Yu 
> 
> From: Vikas Shivappa 
> 
> Add a new cgroup 'intel_rdt' to manage cache allocation. Each cgroup
> directory is associated with a class of service id(closid). To map a
> task with closid during scheduling, this patch removes the closid field
> from task_struct and uses the already existing 'cgroups' field in
> task_struct.
> 
> The cgroup has a file 'l3_cbm' which represents the L3 cache capacity
> bitmask(CBM). The CBM is global for the whole system currently. The
> capacity bitmask needs to have only contiguous bits set and number of
> bits that can be set is less than the max bits that can be set. The
> tasks belonging to a cgroup get to fill in the L3 cache represented by
> the capacity bitmask of the cgroup. For ex: if the max bits in the CBM
> is 10 and the cache size is 10MB, each bit represents 1MB of cache
> capacity.
> 
> Root cgroup always has all the bits set in the l3_cbm. User can create
> more cgroups with mkdir syscall. By default the child cgroups inherit
> the capacity bitmask(CBM) from parent. User can change the CBM specified
> in hex for each cgroup. Each unique bitmask is associated with a class
> of service ID and an -ENOSPC is returned once we run out of
> closids.

This is still the original crap. No, we are not introducing this
interface now just because we can. I explained in great length why
this is completely useless and what we really need.

Thanks,

tglx


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V16 11/11] x86,cgroup/intel_rdt : Add a cgroup interface to manage Intel cache allocation

[Thomas Gleixner]

On Thu, 17 Dec 2015, Fenghua Yu wrote:

> From: Fenghua Yu 
> 
> From: Vikas Shivappa 
> 
> Add a new cgroup 'intel_rdt' to manage cache allocation. Each cgroup
> directory is associated with a class of service id(closid). To map a
> task with closid during scheduling, this patch removes the closid field
> from task_struct and uses the already existing 'cgroups' field in
> task_struct.
> 
> The cgroup has a file 'l3_cbm' which represents the L3 cache capacity
> bitmask(CBM). The CBM is global for the whole system currently. The
> capacity bitmask needs to have only contiguous bits set and number of
> bits that can be set is less than the max bits that can be set. The
> tasks belonging to a cgroup get to fill in the L3 cache represented by
> the capacity bitmask of the cgroup. For ex: if the max bits in the CBM
> is 10 and the cache size is 10MB, each bit represents 1MB of cache
> capacity.
> 
> Root cgroup always has all the bits set in the l3_cbm. User can create
> more cgroups with mkdir syscall. By default the child cgroups inherit
> the capacity bitmask(CBM) from parent. User can change the CBM specified
> in hex for each cgroup. Each unique bitmask is associated with a class
> of service ID and an -ENOSPC is returned once we run out of
> closids.

This is still the original crap. No, we are not introducing this
interface now just because we can. I explained in great length why
this is completely useless and what we really need.

Thanks,

tglx


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/