From: Juan Quintela <quintela@mandrakesoft.com>
To: "Andrey Borzenkov" <arvidjaar@mail.ru>
Cc: linux-kernel@vger.kernel.org, chmouel@mandrakesoft.com
Subject: Re: Does file read-ahead in 2.4 really read ahead?
Date: 16 Jan 2003 17:46:21 +0100 [thread overview]
Message-ID: <m2of6hvy8y.fsf@demo.mitica> (raw)
In-Reply-To: <E18WvfL-0000rr-00@f13.mail.ru>
>>>>> "andrey" == Andrey Borzenkov <arvidjaar@mail.ru> writes:
The last time that I looked, file_readahead was basically not used
in the whole kernel. Sorry for the delay.
Later, Juan.
andrey> The following analysis is based on Mandrake 2.4.20-2mdk kernel, but the problems exists since 2.4.18 and probably earlier so it is unlikely to be a Mandrake-specific. I have pure IDE hardware; situation may be different on SCSI.
andrey> It appears that when do_generic_file_read queues readahead requests, it never ever runs tq_disk to trigger actual read. And in the worst case (when it is the first request in queue) it means that device queue remains plugged until next run_task_queue run. The effects are
andrey> - read-ahead may be delayed for as long as next read from device. In case of busy system doing much disk IO it is not as obvious (because tq_disk is run often); in case of single-user system running single-threaded aplication it makes read-ahead actually useless.
andrey> - it kills supermount. Supermount checks for media change on every file operation (sans actual read). For IDE ide_do_request blocks until queue is unplugged. In the worst case it happens first on next kupdated run i.e. 5 seconds. That explains terrible performance of supermount on CDs under some usage patterns (rpm /mnt/cdrom/*.rpm being the best example).
andrey> Comment at the end of generic_file_readahead suggets that it should unplug the queue:
andrey> /*
andrey> * If we tried to read ahead some pages,
andrey> * If we tried to read ahead asynchronously,
andrey> * Try to force unplug of the device in order to start an asynchronous
andrey> * read IO request.
andrey> but it never happens as far as I can tell.
andrey> Is it intended behaviour?
andrey> -andrey
andrey> P.S. Please Cc on replies as I am not on lkml
andrey> P.P.S. Juan, Chmouel, I have patch for yet another bug that makes IDE CD-ROMs usable with supermount again, need to verify it. Unfortunately it cannot be generalized for HDs or SCSI devices.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
prev parent reply other threads:[~2003-01-16 16:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-10 9:41 Does file read-ahead in 2.4 really read ahead? Andrey Borzenkov
2003-01-16 16:46 ` Juan Quintela [this message]
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=m2of6hvy8y.fsf@demo.mitica \
--to=quintela@mandrakesoft.com \
--cc=arvidjaar@mail.ru \
--cc=chmouel@mandrakesoft.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 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.