All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alan D. Brunelle" <Alan.Brunelle@hp.com>
To: linux-s390@vger.kernel.org, linux-btrace@vger.kernel.org
Subject: Re: [Patch] blkiomon: repost with some fixes and improvements
Date: Mon, 21 Jul 2008 19:34:54 +0000	[thread overview]
Message-ID: <4884E4DE.6010102@hp.com> (raw)
In-Reply-To: <4884DD6B.6060709@gmail.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: "Alan D. Brunelle" <Alan.Brunelle@hp.com>
To: linux-s390@vger.kernel.org, linux-btrace@vger.kernel.org
Subject: Re: [Patch] blkiomon: repost with some fixes and improvements
Date: Mon, 21 Jul 2008 19:34:54 +0000	[thread overview]
Message-ID: <4884E4DE.6010102@hp.com> (raw)
In-Reply-To: <4884DD6B.6060709@gmail.com>

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

  reply	other threads:[~2008-07-21 19:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-18 10:31 [Patch] blkiomon: repost with some fixes and improvements Martin Peschke
2008-07-18 10:45 ` Török Edwin
2008-07-18 13:24 ` Alan D. Brunelle
2008-07-18 15:15 ` Alan D. Brunelle
2008-07-18 15:18 ` Török Edwin
2008-07-18 15:28 ` Alan D. Brunelle
2008-07-18 20:44 ` Török Edwin
2008-07-18 22:59 ` Alan D. Brunelle
2008-07-21 18:45 ` Alan D. Brunelle
2008-07-21 18:56 ` Török Edwin
2008-07-21 19:03 ` Török Edwin
2008-07-21 19:34   ` Alan D. Brunelle [this message]
2008-07-21 19:34     ` Alan D. Brunelle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4884E4DE.6010102@hp.com \
    --to=alan.brunelle@hp.com \
    --cc=linux-btrace@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.