On Tue, 7 Feb 2017, Stephane Eranian wrote:
>
> I think the design must ensure that the following usage models can be
> monitored:
>- the allocations in your CAT partitions
>- the allocations from a task (inclusive of children tasks)
>- the allocations from a group of tasks (inclusive
Tony,
On Tue, Feb 7, 2017 at 10:52 AM, Luck, Tony wrote:
> On Tue, Feb 07, 2017 at 12:08:09AM -0800, Stephane Eranian wrote:
>> Hi,
>>
>> I wanted to take a few steps back and look at the overall goals for
>> cache monitoring.
>> From the various threads and discussion, my understanding is as fol
On Fri, Jan 20, 2017 at 12:11:53PM -0800, David Carrillo-Cisneros wrote:
> Implementation ideas:
>
> First idea is to expose one monitoring file per resource in a CTRLGRP,
> so the list of CTRLGRP's files would be: schemata, tasks, cpus,
> monitor_l3_0, monitor_l3_1, ...
>
> the monitor_ file des
On Fri, Jan 20, 2017 at 03:51:48PM -0800, Shivappa Vikas wrote:
> I think the email thread is going very long and we should just meet f2f
> probably next week to iron out the requirements and chalk out a design
> proposal.
The thread isn't the problem; you lot not trimming your emails is
however.
On Tue, 7 Feb 2017, Stephane Eranian wrote:
Hi,
I wanted to take a few steps back and look at the overall goals for
cache monitoring.
From the various threads and discussion, my understanding is as follows.
I think the design must ensure that the following usage models can be monitored:
-
On Tue, Feb 07, 2017 at 12:08:09AM -0800, Stephane Eranian wrote:
> Hi,
>
> I wanted to take a few steps back and look at the overall goals for
> cache monitoring.
> From the various threads and discussion, my understanding is as follows.
>
> I think the design must ensure that the following usag
Hi,
I wanted to take a few steps back and look at the overall goals for
cache monitoring.
>From the various threads and discussion, my understanding is as follows.
I think the design must ensure that the following usage models can be monitored:
- the allocations in your CAT partitions
- the
On Mon, Feb 6, 2017 at 3:27 PM, Luck, Tony wrote:
>> cgroup mode gives a per-CPU breakdown of event and running time, the
>> tool aggregates it into running time vs event count. Both per-cpu
>> breakdown and the aggregate are useful.
>>
>> Piggy-backing on perf's cgroup mode would give us all the
> cgroup mode gives a per-CPU breakdown of event and running time, the
> tool aggregates it into running time vs event count. Both per-cpu
> breakdown and the aggregate are useful.
>
> Piggy-backing on perf's cgroup mode would give us all the above for free.
Do you have some sample output from a p
On Mon, Feb 6, 2017 at 1:22 PM, Luck, Tony wrote:
>> 12) Whatever fs or syscall is provided instead of perf syscalls, it
>> should provide total_time_enabled in the way perf does, otherwise is
>> hard to interpret MBM values.
>
> It seems that it is hard to define what we even mean by memory bandw
On Mon, Feb 6, 2017 at 1:36 PM, Shivappa Vikas wrote:
>
>
> On Mon, 6 Feb 2017, Luck, Tony wrote:
>
>>> 12) Whatever fs or syscall is provided instead of perf syscalls, it
>>> should provide total_time_enabled in the way perf does, otherwise is
>>> hard to interpret MBM values.
>>
>>
>> It seems t
On Mon, 6 Feb 2017, Luck, Tony wrote:
12) Whatever fs or syscall is provided instead of perf syscalls, it
should provide total_time_enabled in the way perf does, otherwise is
hard to interpret MBM values.
It seems that it is hard to define what we even mean by memory bandwidth.
If you are m
> 12) Whatever fs or syscall is provided instead of perf syscalls, it
> should provide total_time_enabled in the way perf does, otherwise is
> hard to interpret MBM values.
It seems that it is hard to define what we even mean by memory bandwidth.
If you are measuring just one task and you find th
Digging through the e-mails from last week to generate a new version
of the requirements I looked harder at this:
> 12) Whatever fs or syscall is provided instead of perf syscalls, it
> should provide total_time_enabled in the way perf does, otherwise is
> hard to interpret MBM values.
This looks
On Fri, Feb 03, 2017 at 01:08:05PM -0800, David Carrillo-Cisneros wrote:
> On Fri, Feb 3, 2017 at 9:52 AM, Luck, Tony wrote:
> > On Thu, Feb 02, 2017 at 06:14:05PM -0800, David Carrillo-Cisneros wrote:
> >> If we tie allocation groups and monitoring groups, we are tying the
> >> meaning of CPUs an
On Fri, Feb 3, 2017 at 9:52 AM, Luck, Tony wrote:
> On Thu, Feb 02, 2017 at 06:14:05PM -0800, David Carrillo-Cisneros wrote:
>> If we tie allocation groups and monitoring groups, we are tying the
>> meaning of CPUs and we'll have to choose between the CAT meaning or
>> the perf meaning.
>>
>> Let'
On Thu, Feb 02, 2017 at 06:14:05PM -0800, David Carrillo-Cisneros wrote:
> If we tie allocation groups and monitoring groups, we are tying the
> meaning of CPUs and we'll have to choose between the CAT meaning or
> the perf meaning.
>
> Let's allow semantics that will allow perf like monitoring to
Something to be aware is that CAT cpus don't work the way CPU
filtering works in perf:
If I have the following CAT groups:
- default group with task TD
- group GC1 with CPU0 and CLOSID 1
- group GT1 with no CPUs and task T1 and CLOSID2
- TD and T1 run on CPU0.
Then T1 will use CLOSID2 and TD
On Thu, Feb 2, 2017 at 3:41 PM, Luck, Tony wrote:
> On Thu, Feb 02, 2017 at 12:22:42PM -0800, David Carrillo-Cisneros wrote:
>> There is no need to change perf(1) to support
>> # perf stat -I 1000 -e intel_cqm/llc_occupancy {command}
>>
>> the PMU can work with resctrl to provide the support thro
On Thu, Feb 02, 2017 at 12:22:42PM -0800, David Carrillo-Cisneros wrote:
> There is no need to change perf(1) to support
> # perf stat -I 1000 -e intel_cqm/llc_occupancy {command}
>
> the PMU can work with resctrl to provide the support through
> perf_event_open, with the advantage that tools oth
On Thu, Feb 2, 2017 at 11:33 AM, Luck, Tony wrote:
>>> Nice to have:
>>> 1) Readout using "perf(1)" [subset of modes that make sense ... tying
>>> monitoring
>>> to resctrl file system will make most command line usage of perf(1) close
>>> to impossible.
>>
>>
>> We discussed this offline a
Hello Peterz/Andi,
On Thu, 2 Feb 2017, Luck, Tony wrote:
Nice to have:
1) Readout using "perf(1)" [subset of modes that make sense ... tying
monitoring
to resctrl file system will make most command line usage of perf(1) close to
impossible.
Vikas is pushing for "-R rdtgroup" ... thou
>> Nice to have:
>> 1) Readout using "perf(1)" [subset of modes that make sense ... tying
>> monitoring
>> to resctrl file system will make most command line usage of perf(1) close to
>> impossible.
>
>
> We discussed this offline and I still disagree that it is close to
> impossible to use
On Wed, 1 Feb 2017, Yu, Fenghua wrote:
From: Andi Kleen [mailto:a...@firstfloor.org]
"Luck, Tony" writes:
9) Measure per logical CPU (pick active RMID in same precedence for
task/cpu as CAT picks CLOSID)
10) Put multiple CPUs into a group
I'm not sure this is a real requirement.
>> 7) Must be able to measure based on existing resctrl CAT group
>> 8) Can get measurements for subsets of tasks in a CAT group (to find
>> the guys hogging the resources)
>> 9) Measure per logical CPU (pick active RMID in same precedence for
>> task/cpu as CAT picks CLOSID)
>
> I
> From: Andi Kleen [mailto:a...@firstfloor.org]
> "Luck, Tony" writes:
> > 9) Measure per logical CPU (pick active RMID in same precedence for
> task/cpu as CAT picks CLOSID)
> > 10) Put multiple CPUs into a group
>
> I'm not sure this is a real requirement. It's just an optimization, right? If
> > I'm not sure this is a real requirement. It's just an optimization,
> > right? If you can assign policies to threads, you can implicitly set it
> > per CPU through affinity (or the other way around).
>
> That's difficult when distinct users/systems do monitoring and system
> management. What
On Wed, Feb 1, 2017 at 4:35 PM, Andi Kleen wrote:
> "Luck, Tony" writes:
>> 9)Measure per logical CPU (pick active RMID in same precedence for
>> task/cpu as CAT picks CLOSID)
>> 10) Put multiple CPUs into a group
>
> I'm not sure this is a real requirement. It's just an optimization,
> ri
"Luck, Tony" writes:
> 9)Measure per logical CPU (pick active RMID in same precedence for
> task/cpu as CAT picks CLOSID)
> 10) Put multiple CPUs into a group
I'm not sure this is a real requirement. It's just an optimization,
right? If you can assign policies to threads, you can implicitl
On Wed, Feb 1, 2017 at 12:08 PM Luck, Tony wrote:
>
> > I was asking for requirements, not a design proposal. In order to make a
> > design you need a requirements specification.
>
> Here's what I came up with ... not a fully baked list, but should allow for
> some useful
> discussion on whether
> I was asking for requirements, not a design proposal. In order to make a
> design you need a requirements specification.
Here's what I came up with ... not a fully baked list, but should allow for
some useful
discussion on whether any of these are not really needed, or if there is a
glaring ho
On Mon, Jan 23, 2017 at 10:47:44AM +0100, Thomas Gleixner wrote:
> So again:
>
> Can please everyone involved write up their specific requirements
> for CQM and stop spamming us with half baken design proposals?
>
> And I mean abstract requirements and not again something which is
> refe
On Fri, 20 Jan 2017, David Carrillo-Cisneros wrote:
> On Fri, Jan 20, 2017 at 5:29 AM Thomas Gleixner wrote:
> > Can you please write up in a abstract way what the design requirements are
> > that you need. So far we are talking about implementation details and
> > unspecfied wishlists, but what w
On Fri, 20 Jan 2017, David Carrillo-Cisneros wrote:
On Fri, Jan 20, 2017 at 1:08 PM, Shivappa Vikas
wrote:
On Fri, 20 Jan 2017, David Carrillo-Cisneros wrote:
On Fri, Jan 20, 2017 at 5:29 AM Thomas Gleixner
wrote:
On Thu, 19 Jan 2017, David Carrillo-Cisneros wrote:
If resctrl grou
On Fri, Jan 20, 2017 at 1:08 PM, Shivappa Vikas
wrote:
>
>
> On Fri, 20 Jan 2017, David Carrillo-Cisneros wrote:
>
>> On Fri, Jan 20, 2017 at 5:29 AM Thomas Gleixner
>> wrote:
>>>
>>>
>>> On Thu, 19 Jan 2017, David Carrillo-Cisneros wrote:
If resctrl groups could lift the restricti
On Fri, 20 Jan 2017, David Carrillo-Cisneros wrote:
On Fri, Jan 20, 2017 at 5:29 AM Thomas Gleixner wrote:
On Thu, 19 Jan 2017, David Carrillo-Cisneros wrote:
If resctrl groups could lift the restriction of one resctl per CLOSID,
then the user can create many resctrl in the way perf cgrou
On Thu, 19 Jan 2017, David Carrillo-Cisneros wrote:
On Thu, Jan 19, 2017 at 6:32 PM, Vikas Shivappa
wrote:
Resending including Thomas , also with some changes. Sorry for the spam
Based on Thomas and Peterz feedback Can think of two design
variants which target:
-Support monitoring and allo
On Fri, Jan 20, 2017 at 12:30 AM, Thomas Gleixner wrote:
> On Thu, 19 Jan 2017, David Carrillo-Cisneros wrote:
>> On Thu, Jan 19, 2017 at 9:41 AM, Thomas Gleixner wrote:
>> > Above you are talking about the same CLOSID and different RMIDS and not
>> > about changing both.
>>
>> The scenario I tal
On Fri, Jan 20, 2017 at 5:29 AM Thomas Gleixner wrote:
>
> On Thu, 19 Jan 2017, David Carrillo-Cisneros wrote:
> >
> > If resctrl groups could lift the restriction of one resctl per CLOSID,
> > then the user can create many resctrl in the way perf cgroups are
> > created now. The advantage is that
On Thu, Jan 19, 2017 at 6:32 PM, Vikas Shivappa
wrote:
>
> Resending including Thomas , also with some changes. Sorry for the spam
>
> Based on Thomas and Peterz feedback Can think of two design
> variants which target:
>
> -Support monitoring and allocating using the same resctrl group.
> user ca
On Thu, 19 Jan 2017, David Carrillo-Cisneros wrote:
>
> If resctrl groups could lift the restriction of one resctl per CLOSID,
> then the user can create many resctrl in the way perf cgroups are
> created now. The advantage is that there wont be cgroup hierarchy!
> making things much simpler. Also
On Thu, 19 Jan 2017, David Carrillo-Cisneros wrote:
> On Thu, Jan 19, 2017 at 9:41 AM, Thomas Gleixner wrote:
> > Above you are talking about the same CLOSID and different RMIDS and not
> > about changing both.
>
> The scenario I talked about implies changing CLOSID without affecting
> monitoring
On Thu, Jan 19, 2017 at 6:32 PM, Vikas Shivappa
wrote:
> Resending including Thomas , also with some changes. Sorry for the spam
>
> Based on Thomas and Peterz feedback Can think of two design
> variants which target:
>
> -Support monitoring and allocating using the same resctrl group.
> user can
On Thu, Jan 19, 2017 at 9:41 AM, Thomas Gleixner wrote:
> On Wed, 18 Jan 2017, David Carrillo-Cisneros wrote:
>> On Wed, Jan 18, 2017 at 12:53 AM, Thomas Gleixner wrote:
>> There are use cases where the RMID to CLOSID mapping is not that simple.
>> Some of them are:
>>
>> 1. Fine-tuning of cache
Resending including Thomas , also with some changes. Sorry for the spam
Based on Thomas and Peterz feedback Can think of two design
variants which target:
-Support monitoring and allocating using the same resctrl group.
user can use a resctrl group to allocate resources and also monitor
them (wi
Hello Peterz,
On Wed, 18 Jan 2017, Peter Zijlstra wrote:
On Wed, Jan 18, 2017 at 09:53:02AM +0100, Thomas Gleixner wrote:
The whole approach you and David have taken is to whack some desired cgroup
functionality and whatever into CQM without rethinking the overall
design. And that's fundament
On Thu, 19 Jan 2017, David Carrillo-Cisneros wrote:
> A 1:1 mapping between CLOSID/"Resource group" to RMID, as Fenghua suggested
> is very problematic because the number of CLOSIDs is much much smaller than
> the
> number of RMIDs, and, as Stephane mentioned it's a common use case to want to
> in
On Wed, 18 Jan 2017, Stephane Eranian wrote:
> On Wed, Jan 18, 2017 at 12:53 AM, Thomas Gleixner wrote:
> >
> Your use case is specific to HPC and not Web workloads we run. Jobs run
> in cgroups which may span all the CPUs of the machine. CAT may be used
> to partition the cache. Cgroups would
On Wed, 18 Jan 2017, David Carrillo-Cisneros wrote:
> On Wed, Jan 18, 2017 at 12:53 AM, Thomas Gleixner wrote:
> There are use cases where the RMID to CLOSID mapping is not that simple.
> Some of them are:
>
> 1. Fine-tuning of cache allocation. We may want to have a CLOSID for a thread
> during p
On Wed, Jan 18, 2017 at 6:09 PM, David Carrillo-Cisneros
wrote:
> On Wed, Jan 18, 2017 at 12:53 AM, Thomas Gleixner wrote:
>> On Tue, 17 Jan 2017, Shivappa Vikas wrote:
>>> On Tue, 17 Jan 2017, Thomas Gleixner wrote:
>>> > On Fri, 6 Jan 2017, Vikas Shivappa wrote:
>>> > > - Issue(1): Inaccurate d
On Wed, Jan 18, 2017 at 12:53 AM, Thomas Gleixner wrote:
> On Tue, 17 Jan 2017, Shivappa Vikas wrote:
>> On Tue, 17 Jan 2017, Thomas Gleixner wrote:
>> > On Fri, 6 Jan 2017, Vikas Shivappa wrote:
>> > > - Issue(1): Inaccurate data for per package data, systemwide. Just prints
>> > > zeros or arbit
Based on Thomas and Peterz feedback Can think of two variants which target:
-Support monitoring and allocating using the same resctrl group.
user can use a resctrl group to allocate resources and also monitor
them (with respect to tasks or cpu)
-allows 'task only' monitoring outside of resctrl.
On Wed, Jan 18, 2017 at 12:53 AM, Thomas Gleixner wrote:
> On Tue, 17 Jan 2017, Shivappa Vikas wrote:
>> On Tue, 17 Jan 2017, Thomas Gleixner wrote:
>> > On Fri, 6 Jan 2017, Vikas Shivappa wrote:
>> > > - Issue(1): Inaccurate data for per package data, systemwide. Just prints
>> > > zeros or arbit
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> On Tue, 17 Jan 2017, Shivappa Vikas wrote:
> > On Tue, 17 Jan 2017, Thomas Gleixner wrote:
> > > On Fri, 6 Jan 2017, Vikas Shivappa wrote:
> > > > - Issue(1): Inaccurate data for per package data, systemwide. Just
> > > > prints zeros or arbitra
On Wed, Jan 18, 2017 at 12:53 AM, Thomas Gleixner wrote:
> On Tue, 17 Jan 2017, Shivappa Vikas wrote:
>> On Tue, 17 Jan 2017, Thomas Gleixner wrote:
>> > On Fri, 6 Jan 2017, Vikas Shivappa wrote:
>> > > - Issue(1): Inaccurate data for per package data, systemwide. Just prints
>> > > zeros or arbit
On Wed, 18 Jan 2017, Thomas Gleixner wrote:
On Tue, 17 Jan 2017, Shivappa Vikas wrote:
On Tue, 17 Jan 2017, Thomas Gleixner wrote:
On Fri, 6 Jan 2017, Vikas Shivappa wrote:
- Issue(1): Inaccurate data for per package data, systemwide. Just prints
zeros or arbitrary numbers.
Fix: Patches fi
On Wed, Jan 18, 2017 at 09:53:02AM +0100, Thomas Gleixner wrote:
> The whole approach you and David have taken is to whack some desired cgroup
> functionality and whatever into CQM without rethinking the overall
> design. And that's fundamentaly broken because it does not take cache (and
> memory b
On Tue, 17 Jan 2017, Shivappa Vikas wrote:
> On Tue, 17 Jan 2017, Thomas Gleixner wrote:
> > On Fri, 6 Jan 2017, Vikas Shivappa wrote:
> > > - Issue(1): Inaccurate data for per package data, systemwide. Just prints
> > > zeros or arbitrary numbers.
> > >
> > > Fix: Patches fix this by just throwin
On Tue, 17 Jan 2017, Thomas Gleixner wrote:
On Fri, 6 Jan 2017, Vikas Shivappa wrote:
Cqm(cache quality monitoring) is part of Intel RDT(resource director
technology) which enables monitoring and controlling of processor shared
resources via MSR interface.
We know that already. No need for
On Fri, 6 Jan 2017, Vikas Shivappa wrote:
> Cqm(cache quality monitoring) is part of Intel RDT(resource director
> technology) which enables monitoring and controlling of processor shared
> resources via MSR interface.
We know that already. No need for advertising this over and over.
> Below are
Resending version 5 with updated send list. Sorry for the spam.
Cqm(cache quality monitoring) is part of Intel RDT(resource director
technology) which enables monitoring and controlling of processor shared
resources via MSR interface.
The current upstream cqm(Cache monitoring) has major issues wh
61 matches
Mail list logo
