From: Martin Steigerwald <ms@teamix.de>
To: Werner Fischer <devlists@wefi.net>
Cc: Jens Axboe <axboe@kernel.dk>, Jeff Moyer <jmoyer@redhat.com>,
"fio@vger.kernel.org" <fio@vger.kernel.org>,
Christoph Hellwig <hch@infradead.org>,
Florian Haas <f.g.haas@gmx.net>
Subject: Re: Linux I/O stack design question
Date: Tue, 27 Sep 2011 16:06:57 +0200 [thread overview]
Message-ID: <201109271606.58334.ms@teamix.de> (raw)
In-Reply-To: <1315809396.2164.6.camel@werner-t410>
Hi Werner!
Am Montag, 12. September 2011 schrieb Werner Fischer:
> On Don, 2011-09-08 at 14:39 +0200, Jens Axboe wrote:
> > On 2011-09-05 16:01, Werner Fischer wrote:
> > > On Don, 2011-09-01 at 15:13 -0600, Jens Axboe wrote:
> > >> [...]
> > >> I mean that every device should plug in at the same place. There are
> > >> definite up and down sides to plugging in at the stacking level and
> > >> bypassing the IO scheduler. So you have to weight the pros and cons
> > >> before doing that. We need to fix this. Drivers doing that lose out on
> > >> other features in the name of a bit more performance, that's just not
> > >> acceptable.
> > >
> > > I have updated the diagram according to all of your hints:
> > > http://www.thomas-krenn.com/de/wikiDE/images/0/07/Linux-IO-Stack.png
> > >
> > > I had also some off-list discussion with Florian Haas, who convinced me
> > > that the file systems are below of the page cache. I hope this is now
> > > correct.
> >
> > Not sure I'd agree with that, I'd place the page cache between the fs
> > and the storage layer.
>
> After some further off-list feedback from Christoph Hellwig I did some
> updates on the block diagram, including moving the page cache from above
> the fs layer to next to the fs layer (Christoph told me that the page
> cache is a helper function for the file systems).
> I also added SCSI mid layer, SCSI low layer, libata and so on:
> http://www.thomas-krenn.com/de/wikiDE/images/0/07/Linux-IO-Stack.png
>
> I'm looking forward to further feedback.
Not that I would like to use it, but where would dmraid sit? I think it would
be a bit nearer to the SCSI low layer...
I am not quite used to the placement of the page cache, but if its merely a
helper function for filesystems... Regarding performance measurements it makes
a lot of difference. I think the current diagram hides the impact of using
pagecache or not using it a bit. So maybe at least coloring it differently
would give it a bit more visual weight.
Aside from that I find this very detailed and I learned quite a bit from just
looking at it.
Can you make that image available as SVG too?
Thanks,
--
Martin Steigerwald - teamix GmbH - http://www.teamix.de
gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90
next prev parent reply other threads:[~2011-09-27 14:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-01 12:33 Linux I/O stack design question Werner Fischer
2011-09-01 14:19 ` Jeff Moyer
2011-09-01 20:14 ` Werner Fischer
2011-09-01 20:17 ` Jens Axboe
2011-09-01 20:27 ` Werner Fischer
2011-09-01 21:13 ` Jens Axboe
2011-09-05 14:01 ` Werner Fischer
2011-09-08 12:39 ` Jens Axboe
2011-09-12 6:36 ` Werner Fischer
2011-09-27 14:06 ` Martin Steigerwald [this message]
2012-03-06 10:46 ` Announce: Linux I/O stack diagram (was: Re: Linux I/O stack design question) Werner Fischer
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=201109271606.58334.ms@teamix.de \
--to=ms@teamix.de \
--cc=axboe@kernel.dk \
--cc=devlists@wefi.net \
--cc=f.g.haas@gmx.net \
--cc=fio@vger.kernel.org \
--cc=hch@infradead.org \
--cc=jmoyer@redhat.com \
/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.