Jens Axboe's blk-11 causing problems

Jens Axboe's blk-11 causing problems

[Boszormenyi Zoltan]

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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Jens Axboe's blk-11 causing problems

[Jens Axboe]

[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]

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 <axboe@suse.de>
* SuSE Labs

[-- Attachment #2: blk-11-sg-1 --]
[-- Type: text/plain, Size: 399 bytes --]

--- /opt/kernel/linux-2.4.0-test11/drivers/scsi/sg.c	Tue Oct 24 22:58:20 2000
+++ drivers/scsi/sg.c	Fri Nov 24 21:57:50 2000
@@ -689,6 +689,7 @@
 		(void *)SRpnt->sr_buffer, hp->dxfer_len,
 		sg_cmd_done_bh, timeout, SG_DEFAULT_RETRIES);
     /* dxfer_len overwrites SRpnt->sr_bufflen, hence need for b_malloc_len */
+    generic_unplug_device(&SRpnt->sr_device->request_queue);
     return 0;
 }