On 02/04/11 12:51, Christoph Bartoschek wrote:
> Am Freitag 04 Februar 2011 schrieb David Ahern:
> 
>> You can determine time blocked on read (and other system calls) by
>> acquiring all context switches:
>>
>>     perf record -e cs -c 1 -a
>>
>> From there you'll want to generate a time history output. To use
>> unmodified perf code use the -D option to dump raw samples (perf report
>> -D). You can find the process of interest and the kernel timestamp
>> between schedule out events -- and the sched out event before your
>> process. Together you can piece together the time you blocked on read.
>>
>> Alternatively, there are add-on patches which dump the timehistory in a
>> pretty print format:
>>
>> http://www.mail-archive.com/linux-perf-users@vger.kernel.org/msg00049.html
>> http://www.mail-archive.com/linux-perf-users@vger.kernel.org/msg00047.html
>> http://www.mail-archive.com/linux-perf-users@vger.kernel.org/msg00048.html
>>
>>
>> That output can be manipulated much easier to determine time on the
>> processor and time between schedule-in events.
>>
>> Not the complete picture of what I think you are looking for -- but a
>> way to get the time blocked on syscall stats via perf.
> 
> Looks quite complicated to get such a profile. However I have to check it, 
> when I'm back at work.

Can be - depends on the insights you seek. It's been invaluable data for
the product I work on. Attached is a couple of snippets from a local
timehist-analysis tool (workflow is 'perf record', dump timehistory, run
timehist-analysis to time sort the samples, etc).

David


> 
> Thanks
> Christoph