2003-01-10 09:32:50

by Andrey Borzenkov

[permalink] [raw]
Subject: Does file read-ahead in 2.4 really read ahead?

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.

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

- 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.

- 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).

Comment at the end of generic_file_readahead suggets that it should unplug the queue:

/*
* If we tried to read ahead some pages,
* If we tried to read ahead asynchronously,
* Try to force unplug of the device in order to start an asynchronous
* read IO request.

but it never happens as far as I can tell.

Is it intended behaviour?

-andrey

P.S. Please Cc on replies as I am not on lkml

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.


2003-01-16 16:28:47

by Juan Quintela

[permalink] [raw]
Subject: Re: Does file read-ahead in 2.4 really read ahead?

>>>>> "andrey" == Andrey Borzenkov <[email protected]> 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