Hi Dmitry,
Yes, I know, the non-portability of perf.data is a big issue, and one
of the design goals of spr-replay.
The generated program by spr-replay is perfectly portable, but
due to the way perf data format is, they are not. We can't do anything
about perf.data, but the spr-replay program sho
On 04/12/2012 04:51 PM, Pantelis Antoniou wrote:
The data file is not readable by me version of perf.
Oops. This should be investigated. We definitely wants the perf
data to be portable (or, at least, portable with some limitations
between different hardware of the same major architecture).
C
Hi Dmitry,
On Apr 11, 2012, at 11:02 AM, Dmitry Antipov wrote:
> On 04/09/2012 09:24 PM, Pantelis Antoniou wrote:
>
>> Here's a updated patch for builtin-sched.c that should fix your issues.
>>
>> Now when you issue list a field will show the amount of nsecs the
>> task was burning cycles.
>>
On 04/09/2012 09:24 PM, Pantelis Antoniou wrote:
Here's a updated patch for builtin-sched.c that should fix your issues.
Now when you issue list a field will show the amount of nsecs the
task was burning cycles.
It should also fix the crash you've encountered.
1) IIUC, 'perf sched spr-replay
Amit,
I haven't the faintest clue of how many ARM toolchains I have on the box right
now.
I just grab the latest one I installed.
Regards
-- Pantelis
On Apr 10, 2012, at 1:12 PM, Amit Kucheria wrote:
> Pantelis,
>
> Why would you use anything other than the kick-ass ARM toolchain that Linaro
Pantelis,
Why would you use anything other than the kick-ass ARM toolchain that
Linaro is providing for over a year now? ;-)
/Amit
On Tue, Apr 10, 2012 at 12:46 PM, Pantelis Antoniou <
pa...@antoniou-consulting.com> wrote:
> Hi Dmitry,
>
> I use a somewhat older compiler that doesn't whine so m
Hi Dmitry,
I use a somewhat older compiler that doesn't whine so much, so I don't
see those warnings (don't get me started on how annoying gcc is lately).
Sent me a compile log and I'll fix them.
Regards
-- Pantelis
> panto@orpheus:~/ti$ ${CROSS_COMPILE}gcc --version
> arm-angstrom-linux-gnue
On 04/09/2012 09:24 PM, Pantelis Antoniou wrote:
Here's a updated patch for builtin-sched.c that should fix your issues.
Now when you issue list a field will show the amount of nsecs the
task was burning cycles.
It should also fix the crash you've encountered.
Thanks, I'm trying it now.
BTW
Hi Dmitry,
On Apr 9, 2012, at 1:07 PM, Dmitry Antipov wrote:
> On 04/04/2012 05:10 PM, Pantelis Antoniou wrote:
>
>> The reason for the slowdown is that perf sched record default settings is
>> tuned for x86 pretty much, and there's a huge amount of data being generated.
>>
>> perf sched recor
On 04/04/2012 05:10 PM, Pantelis Antoniou wrote:
The reason for the slowdown is that perf sched record default settings is
tuned for x86 pretty much, and there's a huge amount of data being generated.
perf sched record is just a wrapper for perf record so try using this script
for recording:
Dmitry,
The reason for the slowdown is that perf sched record default settings is
tuned for x86 pretty much, and there's a huge amount of data being generated.
perf sched record is just a wrapper for perf record so try using this script
for recording:
> #!/bin/sh
> perf record \
> -a \
>
On Apr 4, 2012, at 1:13 PM, Dmitry Antipov wrote:
> On 04/02/2012 02:18 PM, Pantelis Antoniou wrote:
>
>> Ah, about the load it's because perf sched record adds too many events to the
>> recording (and configuring small buffers for perf). Using a smaller set
>> of events works much better.
>
>
Hi Dmitry,
There is big difference between threads and processes as far as the kernel
is concerned; both are performed by just a clone syscall, and share or
not address space/fd's etc.
If you want to replay per-process workloads, you can just
record only the activity of the pids of the threads o
On 04/02/2012 02:18 PM, Pantelis Antoniou wrote:
Ah, about the load it's because perf sched record adds too many events to the
recording (and configuring small buffers for perf). Using a smaller set
of events works much better.
I tried with a different subsets of 'sched:*' events, but it didn'
On 04/02/2012 02:15 PM, Pantelis Antoniou wrote:
Example session:
# perf sched record
< run process, etc.>
^C<- perf ends producing a perf.data file.
# perf sched spr-replay -l
# perf sched spr-replay -s -s -d -n -g
# perf sched spr-replay -s -g>test.spr
# perf sched spr-replay -f
Dmitry,
Ah, about the load it's because perf sched record adds too many events to the
recording (and configuring small buffers for perf). Using a smaller set
of events works much better.
One thing I did was to record on /tmp - You have enough memory for this to
work. I'll try to come up with the
On 03/08/2012 05:20 PM, Pantelis Antoniou wrote:
The current issue is that scheduler development is not easily shared between
developers. Each developer has their own 'itch', be it Android use cases, server
workloads, VM, etc. The risk is high of optimizing for one's own use case and
causing sev
On Thu, Mar 8, 2012 at 6:50 PM, Pantelis Antoniou
wrote:
>
> Hi there,
>
> There's considerable activity in the subject of the scheduler lately and how
> to
> adapt it to the peculiarities of the new class of hardware coming out lately,
> like the big.LITTLE class of devices from a number of manu
Hi Yadi,
On Mar 8, 2012, at 7:40 PM, Yadwinder Singh Brar wrote:
> On Thu, Mar 8, 2012 at 6:50 PM, Pantelis Antoniou
> wrote:
>>
>> Hi there,
>>
>> There's considerable activity in the subject of the scheduler lately and how
>> to
>> adapt it to the peculiarities of the new class of hardware
On Thu, Mar 08, 2012 at 03:20:53PM +0200, Pantelis Antoniou wrote:
> Hi there,
>
> There's considerable activity in the subject of the scheduler lately and how
> to
> adapt it to the peculiarities of the new class of hardware coming out lately,
> like the big.LITTLE class of devices from a numbe
Hi Frederic,
On Mar 8, 2012, at 5:45 PM, Frederic Weisbecker wrote:
> On Thu, Mar 08, 2012 at 03:20:53PM +0200, Pantelis Antoniou wrote:
>> Hi there,
>>
[snip]
>
> Hi,
>
> May be you could have a look at the perf sched tool.
> It has a replay feature. I think it perform well basic replay but
Hi there,
There's considerable activity in the subject of the scheduler lately and how to
adapt it to the peculiarities of the new class of hardware coming out lately,
like the big.LITTLE class of devices from a number of manufacturers.
The platforms that Linux runs are very diverse, and run dif
22 matches
Mail list logo
