On Mon, 13 Mar 2017, David Carrillo-Cisneros wrote:
> >> I am ok removing the perf-like CPU filtering from the requirements.
> >
> > So if I'm not missing something then ALL remaining requirements can be
> > solved with the RDT integrated monitoring mechanics, right?
> >
>
> Right.
Excellent.
>> I am ok removing the perf-like CPU filtering from the requirements.
>
> So if I'm not missing something then ALL remaining requirements can be
> solved with the RDT integrated monitoring mechanics, right?
>
Right.
On Fri, 10 Mar 2017, David Carrillo-Cisneros wrote:
> > Fine. So we need this for ONE particular use case. And if that is not well
> > documented including the underlying mechanics to analyze the data then this
> > will be a nice source of confusion for Joe User.
> >
> > I still think that this can
>
> Fine. So we need this for ONE particular use case. And if that is not well
> documented including the underlying mechanics to analyze the data then this
> will be a nice source of confusion for Joe User.
>
> I still think that this can be done differently while keeping the overhead
> small.
>
>
On Thu, 9 Mar 2017, David Carrillo-Cisneros wrote:
> On Thu, Mar 9, 2017 at 3:01 AM, Thomas Gleixner wrote:
> > On Wed, 8 Mar 2017, David Carrillo-Cisneros wrote:
> >> On Wed, Mar 8, 2017 at 12:30 AM, Thomas Gleixner
> >> wrote:
> >> > Same applies for per CPU measurements.
> >>
> >> For CPU mea
On Thu, Mar 9, 2017 at 3:01 AM, Thomas Gleixner wrote:
> On Wed, 8 Mar 2017, David Carrillo-Cisneros wrote:
>> On Wed, Mar 8, 2017 at 12:30 AM, Thomas Gleixner wrote:
>> > Same applies for per CPU measurements.
>>
>> For CPU measurements. We need perf-like CPU filtering to support tools
>> that p
On Wed, 8 Mar 2017, David Carrillo-Cisneros wrote:
> On Wed, Mar 8, 2017 at 12:30 AM, Thomas Gleixner wrote:
> > Same applies for per CPU measurements.
>
> For CPU measurements. We need perf-like CPU filtering to support tools
> that perform low overhead monitoring by polling CPU events. These
>
On Wed, Mar 8, 2017 at 12:30 AM, Thomas Gleixner wrote:
> Stephane,
>
> On Tue, 7 Mar 2017, Stephane Eranian wrote:
>> On Tue, Mar 7, 2017 at 12:04 PM, Luck, Tony wrote:
>> >> That's all nice and good, but I still have no coherent explanation why
>> >> measuring across allocation domains makes se
Stephane,
On Tue, 7 Mar 2017, Stephane Eranian wrote:
> On Tue, Mar 7, 2017 at 12:04 PM, Luck, Tony wrote:
> >> That's all nice and good, but I still have no coherent explanation why
> >> measuring across allocation domains makes sense.
> >
> > Is this in reaction to this one?
> >
> >>> 5) P
On Tue, 7 Mar 2017, Stephane Eranian wrote:
Hi,
On Tue, Mar 7, 2017 at 12:04 PM, Luck, Tony wrote:
That's all nice and good, but I still have no coherent explanation why
measuring across allocation domains makes sense.
Is this in reaction to this one?
5) Put multiple threads into a
Hi,
On Tue, Mar 7, 2017 at 12:04 PM, Luck, Tony wrote:
>> That's all nice and good, but I still have no coherent explanation why
>> measuring across allocation domains makes sense.
>
> Is this in reaction to this one?
>
>>> 5) Put multiple threads into a single measurement group
>
> If we fi
Sending the cqm requirements as per Thomas comments in the previous
verson of cqm patch series -
https://marc.info/?l=linux-kernel&m=148374167726502
This is modified version of requirements sent by Tony in the same
thread with inputs from David and Stephan.
Reviewed-by: Tony Luck
Reviewed-by: Dav
On Tue, 7 Mar 2017, Luck, Tony wrote:
> > That's all nice and good, but I still have no coherent explanation why
> > measuring across allocation domains makes sense.
>
> Is this in reaction to this one?
>
> >> 5) Put multiple threads into a single measurement group
>
> If we fix it to say
On Tue, 7 Mar 2017, Vikas Shivappa wrote:
> Sending the cqm requirements as per Thomas comments in the previous
> verson of cqm patch series -
> https://marc.info/?l=linux-kernel&m=148374167726502
>
> This is modified version of requirements sent by Tony in the same
> thread with inputs from Davi
> That's all nice and good, but I still have no coherent explanation why
> measuring across allocation domains makes sense.
Is this in reaction to this one?
>> 5) Put multiple threads into a single measurement group
If we fix it to say "threads from the same CAT group" does it fix things?
15 matches
Mail list logo
