Re: Poor floppy performance in kernel 2.4.10

From: Andrea Arcangeli <andrea@suse.de>
To: alain@linux.lu
Cc: linux-kernel@vger.kernel.org, torvalds@transmeta.com,
	kamil@science.uva.nl, adilger@turbolabs.com,
	vherva@niksula.hut.fi, nleroy@cs.wisc.edu, davidsen@tmr.com,
	viro@math.psu.edu, landley@trommello.org,
	manfred@colorfullife.com
Subject: Re: Poor floppy performance in kernel 2.4.10
Date: Mon, 22 Oct 2001 11:59:56 +0200	[thread overview]
Message-ID: <20011022115956.J8408@athlon.random> (raw)
In-Reply-To: <200110211136.f9LBa9B17801@hitchhiker.org.lu>
In-Reply-To: <200110211136.f9LBa9B17801@hitchhiker.org.lu>; from Alain.Knaff@hitchhiker.org.lu on Sun, Oct 21, 2001 at 01:36:09PM +0200

On Sun, Oct 21, 2001 at 01:36:09PM +0200, Alain Knaff wrote:
> Actually, the floppy drive is able to detect disk changes just fine,
> and since 1.0's the disk change signal (DCL) has been used to trigger
> cache flushing.

I also experienced this correct media change behaviour (even if it's a
long time that I don't use a floppy).

Anyways the check media change is definitely the _right_ fix for the
dvd player stalling because of a backwards seek generated by the fact we
discarded readahead, after waiting synchronoulsy for I/O completion in
truncate_inode_pages in blkdev_close. Turning down the readahead size
can only hide the problem and hurt all the other users (and xine itself
since doing less and large DMA transactions is beneficial for the dvd
too). So I believe in the long run we must implement a whitelist that
tells us when to trust the media change detection, and always trim the
cache during blkdev_open or during rmmod as I also suggested during
2.3.x when blkdev_close was changed to do the unconditional
invalidate_buffers. Current design is a bit simpler but also simply not
smart enough to do the right thing. In the meantime dvd players would
better keep a dummy reference open, and yes, I totally agree it should
be the kernel that has to be fixed and that the userspace workaround can
go away eventually.

BTW, in the xine player stalls thread, Linus said raw (not rawio)
device, but somebody understood rawio, he meant /dev/hdc of course, not
/dev/raw1 with rawio, rawio cannot suffer from the stall generated by
backwards seek because we dropped the readahead. rawio doesn't use cache
or readahead at all. Infact it's interesting to know if rawio suffers
from such stall problem too, if this is the case than the stall have
nothing to do with readadhead or truncate_inode_pages, and it has to be
related to something else (I'd point my finger to the vfs in such a case
because there's not much else involved in the close/open cycle if only
using rawio).

Andrea