From: Andrew Morton <akpm@zip.com.au>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Suparna Bhattacharya <suparna@in.ibm.com>,
Jens Axboe <axboe@suse.de>,
linux-kernel@vger.kernel.org
Subject: Re: One more bio for for floppy users in 2.5.33..
Date: Thu, 05 Sep 2002 11:00:10 -0700 [thread overview]
Message-ID: <3D779BAA.BAA5A742@zip.com.au> (raw)
In-Reply-To: Pine.LNX.4.33.0209051003210.1383-100000@penguin.transmeta.com
Linus Torvalds wrote:
>
> ...
> A fast disk driver will _never ever_ do a partial request completion. A
> high-performance subsystem will put in the scatter-gather list and say
> "go" to the controller, and the controller will send exactly one interrupt
> back when it is all done.
OK. But still, I don't see why we need partial BIO completions. If
we say that the basic unit of completion is a whole BIO, then readahead
can then manage latency via the outgoing bio size.
> So for such a system, you'd never see partial completions anyway.
>
> Partial completions are a feature of slow hardware. And slow hardware is
> exactly when we want to know about it.
Well I'd be interested in knowing specifically what is wrong with the
behaviour of 2.5.33 against a floppy disk.
In the testing I did a few weeks back, everything checked out. An
application which was reading the raw device at 95% of media bandwidth
never blocked. An application which was capable of processing data at
120% of media bandwidth achieved 100%.
It could be that the initial 64k read at the start-of-file is
too big, and the many-small-file behaviour is poor?
A specific "this sucks" testcase would be helpful...
next prev parent reply other threads:[~2002-09-05 17:57 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-03 18:00 One more bio for for floppy users in 2.5.33 Linus Torvalds
2002-09-03 18:02 ` Jens Axboe
2002-09-04 7:25 ` Suparna Bhattacharya
2002-09-04 16:36 ` Linus Torvalds
2002-09-05 7:03 ` Suparna Bhattacharya
2002-09-05 15:06 ` Linus Torvalds
2002-09-05 16:26 ` Andrew Morton
2002-09-05 17:05 ` Linus Torvalds
2002-09-05 18:00 ` Andrew Morton [this message]
2002-09-05 18:28 ` Linus Torvalds
2002-09-05 18:31 ` Jens Axboe
2002-09-05 18:38 ` Linus Torvalds
2002-09-05 18:38 ` Jens Axboe
2002-09-05 19:47 ` Peter Osterlund
2002-09-05 18:42 ` Andrew Morton
2002-09-05 19:03 ` Linus Torvalds
2002-09-05 19:35 ` Andrew Morton
2002-09-05 20:27 ` Linus Torvalds
2002-09-05 20:38 ` Linus Torvalds
2002-09-06 6:47 ` Helge Hafting
2002-09-06 6:59 ` Linus Torvalds
2002-09-09 14:08 ` Bob_Tracy
2002-09-05 20:48 ` Linus Torvalds
2002-09-10 7:25 ` Rogier Wolff
2002-09-10 8:01 ` Andrew Morton
2002-09-07 11:18 ` Daniel Phillips
2002-09-03 20:57 ` Mikael Pettersson
2002-09-03 21:52 ` Linus Torvalds
2002-09-03 22:33 ` Mikael Pettersson
-- strict thread matches above, loose matches on Subject: below --
2002-09-07 14:43 linux
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=3D779BAA.BAA5A742@zip.com.au \
--to=akpm@zip.com.au \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=suparna@in.ibm.com \
--cc=torvalds@transmeta.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.