Krishnendu.Sadhukhan wrote:
>
>Li, Aubrey wrote:
>> Krishnendu Sadhukhan wrote:
>>
> PEBS is important in our NUMAtop design to measure
>
memory access
> latency for application. We will enhance kcpc to
>
support PEBS and
> uncore events. If we can talk with
Krishnendu Sadhukhan wrote:
>>
>> > PEBS is important in our NUMAtop design to measure
>> memory access
>> > latency for application. We will enhance kcpc to
>> support PEBS and
>> > uncore events. If we can talk with CPC engineers
>> and get their help,
>> > it will be great.
>>
>> Yes, I think th
Some supplements:
On Wed, Feb 24, 2010 at 2:43 PM, Li, Aubrey wrote:
> Jonathan Chew wrote:
>>
>>
>>Can you please explain what you mean by CPU, memory, and I/O sensitive?
>
> - CPU sensitive application can be identified by CPU utilization. High CPU
> utilization means the application is CPU sen
Jonathan Chew wrote:
>
>
>Can you please explain what you mean by CPU, memory, and I/O sensitive?
- CPU sensitive application can be identified by CPU utilization. High CPU
utilization means the application is CPU sensitive.
- Memory sensitive application must be CPU sensitive. Besides this, it sh
Li, Aubrey wrote:
Hi Jonathan,
Do you have any comments about this proposal?
Thanks,
-Aubrey
Li, Aubrey wrote:
Jonathan Chew wrote:
Thanks for summarizing the metrics. However, I wanted to see a summary
of the overall NUMAtop proposal given the feedback that you have gotten,
so I ca
Hi Jonathan,
Do you have any comments about this proposal?
Thanks,
-Aubrey
Li, Aubrey wrote:
>
>Jonathan Chew wrote:
>>
>>Thanks for summarizing the metrics. However, I wanted to see a summary
>>of the overall NUMAtop proposal given the feedback that you have gotten,
>>so I can understand what
Jonathan Chew wrote:
>
>Thanks for summarizing the metrics. However, I wanted to see a summary
>of the overall NUMAtop proposal given the feedback that you have gotten,
>so I can understand what the project is proposing to do now that you
>have gotten feedback. Then I can decide whether I have an
Li, Aubrey wrote:
Hi Jonathan,
Nice to see you have interest.
We are discussing the metrics of NUMAtop, and so far the proposal is
that the following parameters will be reported by NUMAtop as the metrics.
1) sysload - cpu sensitive
2) LLC Miss per Instruction - memory sensitive
3) LLC La
On Wed, Jan 20, 2010 at 2:46 AM, Krishnendu Sadhukhan
wrote:
>>
>> > PEBS is important in our NUMAtop design to measure
>> memory access
>> > latency for application. We will enhance kcpc to
>> support PEBS and
>> > uncore events. If we can talk with CPC engineers
>> and get their help,
>> > it wi
>
> > PEBS is important in our NUMAtop design to measure
> memory access
> > latency for application. We will enhance kcpc to
> support PEBS and
> > uncore events. If we can talk with CPC engineers
> and get their help,
> > it will be great.
>
> Yes, I think that's essential. I'll put you guys in
PEBS is important in our NUMAtop design to measure memory access
latency for application. We will enhance kcpc to support PEBS and
uncore events. If we can talk with CPC engineers and get their help,
it will be great.
Yes, I think that's essential. I'll put you guys in contact
with each other.
On Mon, Jan 18, 2010 at 5:31 PM, Jon Haslam wrote:
> Hi Aubrey,
>
>> NUMAtop will focus on NUMA-related characteristic. Yes, the information is
>> collected from memory-related hardware counters. Some of these counters
>> are
>> already supported in kcpc and libcpc, while some of them are not. We
Hi Aubrey,
NUMAtop will focus on NUMA-related characteristic. Yes, the information is
collected from memory-related hardware counters. Some of these counters are
already supported in kcpc and libcpc, while some of them are not. We probably
need to use Precise Event Based Sampling(PEBS), which se
Alexander Kolbasov wrote:
>
>Aubrey,
>
>> Hi Jonathan,
>>
>> Nice to see you have interest.
>>
>> We are discussing the metrics of NUMAtop, and so far the proposal is
>> that the following parameters will be reported by NUMAtop as the
>metrics.
>>
>> 1) sysload - cpu sensitive
>> 2) LLC Miss per
Aubrey,
> Hi Jonathan,
>
> Nice to see you have interest.
>
> We are discussing the metrics of NUMAtop, and so far the proposal is
> that the following parameters will be reported by NUMAtop as the metrics.
>
> 1) sysload- cpu sensitive
> 2) LLC Miss per Instruction - memory sensitive
> 3)
Hi Jonathan,
Nice to see you have interest.
We are discussing the metrics of NUMAtop, and so far the proposal is
that the following parameters will be reported by NUMAtop as the metrics.
1) sysload - cpu sensitive
2) LLC Miss per Instruction - memory sensitive
3) LLC Latency ratio - memory
There has been a lot of discussion on this since it was proposed last
month. I want to know what is currently being proposed given the
lengthy discussion.
Can someone please summarize what the current proposal is now?
Jonathan
Li, Aubrey wrote:
johansen wrote:
On Tue, Jan 12, 2010 at
On Wed, Jan 13, 2010 at 09:17:47AM +0800, Li, Aubrey wrote:
> johansen wrote:
> >
> >On Tue, Jan 12, 2010 at 02:20:02PM +0800, zhihui Chen wrote:
> >> Application can be categoried into CPU-sensitive, Memory-sensitive,
> >> IO-sensitive.
> >
> >My concern here is that unless the customer knows how
johansen wrote:
>
>On Tue, Jan 12, 2010 at 02:20:02PM +0800, zhihui Chen wrote:
>> Application can be categoried into CPU-sensitive, Memory-sensitive,
>> IO-sensitive.
>
>My concern here is that unless the customer knows how to determine
>whether his application is CPU, memory, or IO sensitive it's
On Tue, Jan 12, 2010 at 02:20:02PM +0800, zhihui Chen wrote:
> Application can be categoried into CPU-sensitive, Memory-sensitive,
> IO-sensitive.
My concern here is that unless the customer knows how to determine
whether his application is CPU, memory, or IO sensitive it's going to be
hard to use
On Wed, Jan 6, 2010 at 5:53 AM, wrote:
> On Tue, Jan 05, 2010 at 04:27:03PM +0800, Li, Aubrey wrote:
>> >I'm concerned that unless we're able to demonstrate some causal
>> >relationship between RMA and reduced performance, it will be hard for
>> >customers to use the tools to diagnose problems.
Thanks johansen, I really appreciate your suggestion.
Use the time cost to replace reporting the number of RMA only,
it should make end user feel more friendly.
old sample
--
(time: 5s):
pid RMA LMA
---
10001 1000300
new sample
--
(time: 5s)
pid
Eric.Saxe wrote:
>
>johan...@sun.com wrote:
>> On Thu, Dec 17, 2009 at 05:07:45PM -0800, Jin Yao wrote:
>>
>>> We decide to divide numatop development into 2 phases.
>>>
>>> At phase 1, numatop is designed as a memory locality characterizing
>tool.
>>> It provides a easy and friendly way for observ
On Tue, Jan 05, 2010 at 04:27:03PM +0800, Li, Aubrey wrote:
> >I'm concerned that unless we're able to demonstrate some causal
> >relationship between RMA and reduced performance, it will be hard for
> >customers to use the tools to diagnose problems. Imagine a situation
> >where the application i
Johansen wrote:
>
>On Thu, Dec 17, 2009 at 05:07:45PM -0800, Jin Yao wrote:
>> We decide to divide numatop development into 2 phases.
>>
>> At phase 1, numatop is designed as a memory locality characterizing
>tool.
>> It provides a easy and friendly way for observing performance data
>from
>> hardw
Johansen gave a good reminding that the RMA possibly was not a root cause for
the application running slowly even if it has high RMA, and provided detail
information for why some memory would be allocated on remote node. Thanks.
>From my point, numatop had better still focus on within the scope
johan...@sun.com wrote:
On Thu, Dec 17, 2009 at 05:07:45PM -0800, Jin Yao wrote:
We decide to divide numatop development into 2 phases.
At phase 1, numatop is designed as a memory locality characterizing tool.
It provides a easy and friendly way for observing performance data from
hardware
On Thu, Dec 17, 2009 at 05:07:45PM -0800, Jin Yao wrote:
> We decide to divide numatop development into 2 phases.
>
> At phase 1, numatop is designed as a memory locality characterizing tool.
> It provides a easy and friendly way for observing performance data from
> hardware performance counte
johansen wrote:
>
>On Wed, Dec 16, 2009 at 09:17:43PM -0800, Krishnendu Sadhukhan wrote:
>> I'd like to request sponsorship from the performance community to host
>a
>> project for NUMAtop for OpenSolaris.
Many thanks to Krish for the sponsorship.
>>
>> NUMAtop is a tool developed by Intel to help
We decide to divide numatop development into 2 phases.
At phase 1, numatop is designed as a memory locality characterizing tool.
It provides a easy and friendly way for observing performance data from
hardware performance counters. Otherwise these data are difficult to
interpret.
At phase 2,
On Wed, Dec 16, 2009 at 09:17:43PM -0800, Krishnendu Sadhukhan wrote:
> I'd like to request sponsorship from the performance community to host a
> project for NUMAtop for OpenSolaris.
>
> NUMAtop is a tool developed by Intel to help developers identify
> memory locality in NUMA systems. It's a top
I'd like to request sponsorship from the performance community to host a
project for NUMAtop for OpenSolaris.
NUMAtop is a tool developed by Intel to help developers identify memory
locality in NUMA systems. It's a top-like utility that shows the top N
processes in the system and their memory lo
32 matches
Mail list logo
