* Dave Hansen wrote:
> On 07/22/2013 03:06 AM, Ingo Molnar wrote:
> > Btw., would be nice to also integrate these VM counters into perf as well,
> > as an instrumentation variant/option.
> >
> > It could be done in an almost zero overhead fashion using jump-labels I
> > think.
> >
> > [
* Dave Hansen d...@sr71.net wrote:
On 07/22/2013 03:06 AM, Ingo Molnar wrote:
Btw., would be nice to also integrate these VM counters into perf as well,
as an instrumentation variant/option.
It could be done in an almost zero overhead fashion using jump-labels I
think.
[ Just
On 07/22/2013 03:06 AM, Ingo Molnar wrote:
> Btw., would be nice to also integrate these VM counters into perf as well,
> as an instrumentation variant/option.
>
> It could be done in an almost zero overhead fashion using jump-labels I
> think.
>
> [ Just in case someone is bored to death and
* Dave Hansen wrote:
> On 07/19/2013 04:38 AM, Raghavendra KT wrote:
> > While measuring non - PLE performance, one of the bottleneck, I am seeing is
> > flush tlbs.
> > perf had helped in alaysing a bit there, but this patch would help
> > in precise calculation. It will aslo help in tuning
* Dave Hansen d...@sr71.net wrote:
On 07/19/2013 04:38 AM, Raghavendra KT wrote:
While measuring non - PLE performance, one of the bottleneck, I am seeing is
flush tlbs.
perf had helped in alaysing a bit there, but this patch would help
in precise calculation. It will aslo help in
On 07/22/2013 03:06 AM, Ingo Molnar wrote:
Btw., would be nice to also integrate these VM counters into perf as well,
as an instrumentation variant/option.
It could be done in an almost zero overhead fashion using jump-labels I
think.
[ Just in case someone is bored to death and is
On 07/19/2013 08:50 PM, Dave Hansen wrote:
On 07/19/2013 04:38 AM, Raghavendra KT wrote:
While measuring non - PLE performance, one of the bottleneck, I am seeing is
flush tlbs.
perf had helped in alaysing a bit there, but this patch would help
in precise calculation. It will aslo help in
On 07/19/2013 08:50 PM, Dave Hansen wrote:
On 07/19/2013 04:38 AM, Raghavendra KT wrote:
While measuring non - PLE performance, one of the bottleneck, I am seeing is
flush tlbs.
perf had helped in alaysing a bit there, but this patch would help
in precise calculation. It will aslo help in
On 07/19/2013 01:28 AM, Ingo Molnar wrote:
> UP is slowly going extinct, but in any case these counters ought to inform
> us about TLB flushes even on UP systems:
>
> > > +NR_TLB_LOCAL_FLUSH_ALL,
> > > +NR_TLB_LOCAL_FLUSH_ONE,
> > > +
On 07/19/2013 04:38 AM, Raghavendra KT wrote:
> While measuring non - PLE performance, one of the bottleneck, I am seeing is
> flush tlbs.
> perf had helped in alaysing a bit there, but this patch would help
> in precise calculation. It will aslo help in tuning the PLE window
> experiments (larger
On Wed, Jul 17, 2013 at 5:14 AM, Dave Hansen wrote:
>
> I was investigating some TLB flush scaling issues and realized
> that we do not have any good methods for figuring out how many
> TLB flushes we are doing.
>
> It would be nice to be able to do these in generic code, but the
>
* Andrew Morton wrote:
> On Wed, 17 Jul 2013 09:21:00 +0200 Ingo Molnar wrote:
>
> >
> > * Dave Hansen wrote:
> >
> > > I was investigating some TLB flush scaling issues and realized
> > > that we do not have any good methods for figuring out how many
> > > TLB flushes we are doing.
> > >
* Andrew Morton a...@linux-foundation.org wrote:
On Wed, 17 Jul 2013 09:21:00 +0200 Ingo Molnar mi...@kernel.org wrote:
* Dave Hansen d...@sr71.net wrote:
I was investigating some TLB flush scaling issues and realized
that we do not have any good methods for figuring out how
On Wed, Jul 17, 2013 at 5:14 AM, Dave Hansen d...@sr71.net wrote:
I was investigating some TLB flush scaling issues and realized
that we do not have any good methods for figuring out how many
TLB flushes we are doing.
It would be nice to be able to do these in generic code, but the
On 07/19/2013 04:38 AM, Raghavendra KT wrote:
While measuring non - PLE performance, one of the bottleneck, I am seeing is
flush tlbs.
perf had helped in alaysing a bit there, but this patch would help
in precise calculation. It will aslo help in tuning the PLE window
experiments (larger PLE
On 07/19/2013 01:28 AM, Ingo Molnar wrote:
UP is slowly going extinct, but in any case these counters ought to inform
us about TLB flushes even on UP systems:
+NR_TLB_LOCAL_FLUSH_ALL,
+NR_TLB_LOCAL_FLUSH_ONE,
+NR_TLB_LOCAL_FLUSH_ONE_KERNEL,
On Wed, 17 Jul 2013 09:21:00 +0200 Ingo Molnar wrote:
>
> * Dave Hansen wrote:
>
> > I was investigating some TLB flush scaling issues and realized
> > that we do not have any good methods for figuring out how many
> > TLB flushes we are doing.
> >
> > It would be nice to be able to do these
On Wed, 17 Jul 2013 09:21:00 +0200 Ingo Molnar mi...@kernel.org wrote:
* Dave Hansen d...@sr71.net wrote:
I was investigating some TLB flush scaling issues and realized
that we do not have any good methods for figuring out how many
TLB flushes we are doing.
It would be nice to be
* Dave Hansen wrote:
> I was investigating some TLB flush scaling issues and realized
> that we do not have any good methods for figuring out how many
> TLB flushes we are doing.
>
> It would be nice to be able to do these in generic code, but the
> arch-independent calls don't explicitly
* Dave Hansen d...@sr71.net wrote:
I was investigating some TLB flush scaling issues and realized
that we do not have any good methods for figuring out how many
TLB flushes we are doing.
It would be nice to be able to do these in generic code, but the
arch-independent calls don't
I was investigating some TLB flush scaling issues and realized
that we do not have any good methods for figuring out how many
TLB flushes we are doing.
It would be nice to be able to do these in generic code, but the
arch-independent calls don't explicitly specify whether we
actually need to do
On 07/16/2013 04:36 PM, Wanpeng Li wrote:
> On Tue, Jul 16, 2013 at 08:53:04AM -0700, Dave Hansen wrote:
>> I was investigating some TLB flush scaling issues and realized
>> that we do not have any good methods for figuring out how many
>> TLB flushes we are doing.
>>
>> It would be nice to be
I was investigating some TLB flush scaling issues and realized
that we do not have any good methods for figuring out how many
TLB flushes we are doing.
It would be nice to be able to do these in generic code, but the
arch-independent calls don't explicitly specify whether we
actually need to do
I was investigating some TLB flush scaling issues and realized
that we do not have any good methods for figuring out how many
TLB flushes we are doing.
It would be nice to be able to do these in generic code, but the
arch-independent calls don't explicitly specify whether we
actually need to do
On 07/16/2013 04:36 PM, Wanpeng Li wrote:
On Tue, Jul 16, 2013 at 08:53:04AM -0700, Dave Hansen wrote:
I was investigating some TLB flush scaling issues and realized
that we do not have any good methods for figuring out how many
TLB flushes we are doing.
It would be nice to be able to do
I was investigating some TLB flush scaling issues and realized
that we do not have any good methods for figuring out how many
TLB flushes we are doing.
It would be nice to be able to do these in generic code, but the
arch-independent calls don't explicitly specify whether we
actually need to do
26 matches
Mail list logo
