linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Alexander Viro <viro@math.psu.edu>
Cc: Andreas Dilger <adilger@turbolabs.com>,
	Kamil Iskra <kamil@science.uva.nl>, Steve Kieu <haiquy@yahoo.com>,
	kernel <linux-kernel@vger.kernel.org>
Subject: Re: Poor floppy performance in kernel 2.4.10
Date: Thu, 18 Oct 2001 19:44:15 +0200	[thread overview]
Message-ID: <20011018194415.S12055@athlon.random> (raw)
In-Reply-To: <20011018092837.C1144@turbolinux.com> <Pine.GSO.4.21.0110181217120.21021-100000@weyl.math.psu.edu>
In-Reply-To: <Pine.GSO.4.21.0110181217120.21021-100000@weyl.math.psu.edu>; from viro@math.psu.edu on Thu, Oct 18, 2001 at 12:18:12PM -0400

On Thu, Oct 18, 2001 at 12:18:12PM -0400, Alexander Viro wrote:
> 
> 
> On Thu, 18 Oct 2001, Andreas Dilger wrote:
> 
> > I think this is a result of the "blockdev in pagecache" change added in
> > 2.4.10.  One of the byproducts of this change is that if a block device
> > is closed (no other openers) then all of the pages from this device are
> > dropped from the cache.  In the case of a floppy drive, this is very
> > important, as you don't want to be cacheing data from one floppy after
> > you have inserted a new floppy.
> 
> 
> RTFS.  That _exactly_ matches the behaviour of buffer-cache variant.

Indeed, only 2.2 trusted the check media change information and left the
cache valid on top of the floppy across close/open of the blkdev.

Maybe it's because a read now fills in the whole page rather than 1k.
So if you write 1k aligned, and you read it back, the read will it the
disk and it will have to read another 3k before it can return such 1k
info that was just in memory. It's exactly the same on the files on a 1k
ext2 filesystem.

Alexander just proposed some month ago to support the partial reads in
the pagecache like we do for partial writes: by not marking the page
uptodate for partial reads and by going down to the buffer layer every
time to check if the partial memory we're interested about is just
uptodate or not (and marking the page uptodate eventually if we end
reading the whole page). So it's nothing unfixable, we just need to
understand if that is the problem and/or if mtools is doing something
stupid that sorted out to work ok when partial reads were supported.

Andrea

  reply	other threads:[~2001-10-18 17:44 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-17  7:36 Poor floppy performance in kernel 2.4.10 Kamil Iskra
2001-10-17 20:45 ` Steve Kieu
2001-10-18 10:11   ` Kamil Iskra
2001-10-18 15:28     ` Andreas Dilger
2001-10-18 15:42       ` Kamil Iskra
2001-10-18 16:17         ` Ville Herva
2001-10-18 16:30           ` Nick LeRoy
2001-10-18 19:57             ` bill davidsen
2001-10-18 20:47               ` Nick LeRoy
2001-10-18 20:05             ` bill davidsen
2001-10-18 20:15               ` Alexander Viro
2001-10-18 16:18       ` Alexander Viro
2001-10-18 17:44         ` Andrea Arcangeli [this message]
2001-10-19  7:50           ` Giuliano Pochini
2001-10-19 13:46             ` Andrea Arcangeli
2001-10-19 15:57             ` Linus Torvalds
2001-10-20  4:20               ` Rob Landley
2001-10-19 16:58 Manfred Spraul
2001-10-21 11:36 Alain Knaff
2001-10-22  9:59 ` Andrea Arcangeli
2001-10-22 10:06   ` Alexander Viro
2001-10-22 14:07 ` Nick LeRoy
2001-10-22 18:28 ` bill davidsen
2001-10-27 15:00 Alain Knaff
2001-10-27 15:15 ` Alexander Viro
2001-10-27 17:12   ` Alain Knaff
2001-10-27 17:42     ` Alexander Viro
2001-10-27 18:00       ` Alain Knaff
2001-10-27 18:13         ` Alexander Viro
2001-10-27 18:26         ` Alexander Viro
2001-11-06  7:01         ` Richard Gooch
2001-11-06  7:03           ` Alexander Viro
2001-11-06  7:19         ` Richard Gooch
2001-11-06  7:22           ` Alexander Viro
2001-10-27 19:13       ` Alain Knaff
2001-10-27 19:19         ` Alexander Viro
2001-10-27 19:26           ` Alain Knaff
2001-10-28 20:40           ` Alain Knaff
2001-10-28 20:57             ` Peter T. Breuer
2001-10-29  5:38               ` Alain Knaff
2001-10-29  6:07                 ` Alexander Viro
2001-10-29  6:34                   ` Alain Knaff
2001-10-28 21:42             ` Alexander Viro

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=20011018194415.S12055@athlon.random \
    --to=andrea@suse.de \
    --cc=adilger@turbolabs.com \
    --cc=haiquy@yahoo.com \
    --cc=kamil@science.uva.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@math.psu.edu \
    /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;
as well as URLs for NNTP newsgroup(s).