* Re: [Patch] blkiomon: repost with some fixes and improvements
[not found] <4884DD6B.6060709@gmail.com>
@ 2008-07-21 19:34 ` Alan D. Brunelle
0 siblings, 0 replies; only message in thread
From: Alan D. Brunelle @ 2008-07-21 19:34 UTC (permalink / raw)
To: linux-s390, linux-btrace
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]
T�r�k Edwin wrote:
> On 2008-07-21 21:56, T�r�k Edwin wrote:
>> On 2008-07-21 21:45, Alan D. Brunelle wrote:
>>
>>> Hi Edwin -
>>>
>>> With the patches sent out today (kernel & application), you can then use
>>> the updated script attached here. It only asks for getrq & sleeprq
>>> traces - so it will cut down a lot, but most likely there will still be
>>> a lot of getrq's (in particular).
>>>
>>> Will now have some time to look at the more general issue concerning how
>>> to see the effects of the sleeprq's...
>>>
>>>
>>
>
> I think it would be useful to somehow "dump" the contents of both queues
> when a sleep occurs, at least
> the rw_flags, the pid, and the size of the operation.
> Maybe that could be done somehow via blktrace on-demand? [it already has
> all the relayfs communication ...]
>
> P.S.: I tried to blktrace all queueing events and save that to the disk,
> but no matter what buffer size I used,
> it kept telling me it has dropped events :(
> So the only way to know the contents of the queue is for the kernel to
> give it to me on-demand.
Hi Edwin -
That's really strange: I very rarely have that problem - I find if I
increase the number and size of buffers, those problems go away. (But, I
tend to have a lot of memory to play with too...)
You are dumping to another disk (other than the one you are tracing), right?
Alan
^ permalink raw reply [flat|nested] only message in thread