public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Felipe Erias <charles.swann@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Queues when accessing disks
Date: Fri, 31 Dec 2004 07:16:01 -0200	[thread overview]
Message-ID: <20041231091601.GB10834@logos.cnet> (raw)
In-Reply-To: <169c13c404123019322a766f64@mail.gmail.com>

On Fri, Dec 31, 2004 at 04:32:59AM +0100, Felipe Erias wrote:
> Hi,

Hi Felipe,

> I'm trying to apply queuing theory to the study of the GNU/Linux kernel.
> Right now, I'm focusing in the queue of processes that appears when they
> try to access an I/O device (specifically, an IDE HD).

Interesting!

> When they want to read data, it behaves as a usual queue: several clients (processes) that
> require attention from a server (disk / driver / ...). The case when they want
> to write data is a bit more tricky, because of the cache buffers used by the OS,
> and maybe could be modelized by a network of queues. 

Well read's also go through the pagecache, so you "suffer" from the same caching 
issue.

> Both cases are
> interesting for my work, but I'll take the reading one first, just
> because it seems
> a bit more simple 'a priori'.
> 
> To modelize the queue, I need to get some information:
>  - what processes claim attention from the disk
>  - when they do it
>  - when they begin to be served
>  - when they finish being served

Its a bit more complicated than that because requests will be often shared, and 
its not always the process who initiates the request who actually perform it.

For example writes are often performed by pdflush (the flushing daemon) and not 
the process(es) which initiated them.

Another thing is that on a real system you will have a _huge_ amount of statistical data.

> To get all this information, maybe I could hack my kernel a bit to write
> a line to a log on every access to the HD, or account the IRQs from
> the IDE channels... I also have the feeling that this queuing problem could
> dissappear o became more hidden if DMA were enabled.
> 
> To be true, I'm a bit lost and that's why I ask for your help.

Linux Trace Toolkit can give you detailed per-process statistics. You should
take a look at it 

http://www.opersys.com/LTT/

Good luck!




  reply	other threads:[~2004-12-31 12:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-31  3:32 Queues when accessing disks Felipe Erias
2004-12-31  9:16 ` Marcelo Tosatti [this message]
2004-12-31 20:26 ` M. Edward Borasky

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=20041231091601.GB10834@logos.cnet \
    --to=marcelo.tosatti@cyclades.com \
    --cc=charles.swann@gmail.com \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox