mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

      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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®