On 05/09/2013 11:05 AM, David Ahern wrote:
On 5/9/13 8:46 AM, Waiman Long wrote:
I am sorry that I forgot to rerun checkpatch.pl again after changing the
argument type from int to bool.
You can edit/create .git/hooks/pre-commit and have it run
checkpatch.pl so you don't forget:
#!/bin/bash
On 5/9/13 8:46 AM, Waiman Long wrote:
I am sorry that I forgot to rerun checkpatch.pl again after changing the
argument type from int to bool.
You can edit/create .git/hooks/pre-commit and have it run checkpatch.pl
so you don't forget:
#!/bin/bash
exec git diff --cached | scripts/checkpatch.
On 05/09/2013 06:19 AM, Jiri Olsa wrote:
On Wed, May 08, 2013 at 11:44:35AM -0400, Waiman Long wrote:
On 05/07/2013 05:30 AM, Jiri Olsa wrote:
On Mon, May 06, 2013 at 09:43:53AM -0400, Waiman Long wrote:
When "perf record" was used on a large machine with a lot of CPUs,
the perf post-processin
* Jiri Olsa wrote:
> On Wed, May 08, 2013 at 11:44:35AM -0400, Waiman Long wrote:
> > On 05/07/2013 05:30 AM, Jiri Olsa wrote:
> > >On Mon, May 06, 2013 at 09:43:53AM -0400, Waiman Long wrote:
> > >>When "perf record" was used on a large machine with a lot of CPUs,
> > >>the perf post-processing
On Wed, May 08, 2013 at 11:44:35AM -0400, Waiman Long wrote:
> On 05/07/2013 05:30 AM, Jiri Olsa wrote:
> >On Mon, May 06, 2013 at 09:43:53AM -0400, Waiman Long wrote:
> >>When "perf record" was used on a large machine with a lot of CPUs,
> >>the perf post-processing time could take a lot of minute
On 05/07/2013 05:30 AM, Jiri Olsa wrote:
On Mon, May 06, 2013 at 09:43:53AM -0400, Waiman Long wrote:
When "perf record" was used on a large machine with a lot of CPUs,
the perf post-processing time could take a lot of minutes and even
hours depending on how large the resulting perf.data file wa
* Waiman Long wrote:
> On 05/07/2013 03:01 AM, Ingo Molnar wrote:
> >* Waiman Long wrote:
> >
> >>When "perf record" was used on a large machine with a lot of CPUs,
> >>the perf post-processing time could take a lot of minutes and even
> >>hours depending on how large the resulting perf.data fi
On 05/07/2013 10:19 AM, Waiman Long wrote:
The slowdown that I was trying to fix was in the "perf record" part of
the profiling process, not the "perf report" part. I didn't try
perf-record on perf-record as the performance counters are limited
resources and I don't want resource conflicts to a
On 05/07/2013 05:30 AM, Jiri Olsa wrote:
On Mon, May 06, 2013 at 09:43:53AM -0400, Waiman Long wrote:
When "perf record" was used on a large machine with a lot of CPUs,
the perf post-processing time could take a lot of minutes and even
hours depending on how large the resulting perf.data file wa
On 05/07/2013 03:01 AM, Ingo Molnar wrote:
* Waiman Long wrote:
When "perf record" was used on a large machine with a lot of CPUs,
the perf post-processing time could take a lot of minutes and even
hours depending on how large the resulting perf.data file was.
While running AIM7 1500-user hig
On Mon, May 06, 2013 at 09:43:53AM -0400, Waiman Long wrote:
> When "perf record" was used on a large machine with a lot of CPUs,
> the perf post-processing time could take a lot of minutes and even
> hours depending on how large the resulting perf.data file was.
>
> While running AIM7 1500-user h
* Waiman Long wrote:
> When "perf record" was used on a large machine with a lot of CPUs,
> the perf post-processing time could take a lot of minutes and even
> hours depending on how large the resulting perf.data file was.
>
> While running AIM7 1500-user high_systime workload on a 80-core x86
When "perf record" was used on a large machine with a lot of CPUs,
the perf post-processing time could take a lot of minutes and even
hours depending on how large the resulting perf.data file was.
While running AIM7 1500-user high_systime workload on a 80-core x86-64
system with a 3.9 kernel, the
13 matches
Mail list logo
