Hi!
I tried 2.4.0-test11 (plain, +ac1/2) with and without
Jens' blk-11 patch. This indeed performs (much) better
when there is only high disk activity but cdrecord
starts up _very_ slowly if the kernel was compiled with
blk-11. It does not happen if blk-11 is not applied.
I stopped cdrecord before it started writing because of
this suspicious slowness and I did not want to create a bad CD.
Other data points:
The CD-writer is a Yamaha-6416 (SCSI version).
The SCSI card is a Diamond Fireport-40 (Symbios 53c875j)
I tested both the in-kernel 1.6b and 1.7.2 versions of the
sym53c8xx driver.
The slowdown was experienced in every case where
the kernel contained blk-11.
Regards,
Zoltan Boszormenyi
On Fri, Nov 24 2000, Boszormenyi Zoltan wrote:
> Hi!
>
> I tried 2.4.0-test11 (plain, +ac1/2) with and without
> Jens' blk-11 patch. This indeed performs (much) better
> when there is only high disk activity but cdrecord
> starts up _very_ slowly if the kernel was compiled with
> blk-11. It does not happen if blk-11 is not applied.
>
> I stopped cdrecord before it started writing because of
> this suspicious slowness and I did not want to create a bad CD.
>
> Other data points:
> The CD-writer is a Yamaha-6416 (SCSI version).
> The SCSI card is a Diamond Fireport-40 (Symbios 53c875j)
> I tested both the in-kernel 1.6b and 1.7.2 versions of the
> sym53c8xx driver.
>
> The slowdown was experienced in every case where
> the kernel contained blk-11.
You might want to send messages such as this one to me
as well, so I don't miss them :-)
The problem is due to sg assuming that scsi_do_req will
fire the request queue immediately to let the command
inject complete. This was never really the case, even
in the stock kernel. Here's a quick-and-dirty patch
against test11+blk-11 attached, untested but it should
fix the delays.
--
* Jens Axboe <[email protected]>
* SuSE Labs