On Thu, 19 Feb 2004 03:26:28, Andrew Morton wrote: > Miquel van Smoorenburg <miquels@cistron.nl> wrote: > > > > The thing is, the bio's are submitted perfectly sequentially. It's just that > > every so often a request (with just its initial bio) gets stuck for a while. > > Because the bio's after it are merged and sent to the device, it's not > > possible to merge that stuck request later on when it gets unstuck, because > > the other bio's have already left the building so to speak. > > Oh. So the raid controller's queue depth is larger than the kernel's. So > everything gets immediately shovelled into the device and the kernel is > left with nothing to merge the little request against. Well, the request queue of the kernel is max'ed out too, otherwise get_request_wait() wouldn't be called. It's just an unfortunate timing issue. > Shouldn't the controller itself be performing the insertion? Well, you would indeed expect the 3ware hardware to be smarter than that, but in its defence, the driver doesn't set sdev->simple_tags or sdev->ordered_tags at all. It just has a large queue on the host, in hardware. Perhaps this info should be exported into the request queue of the device, so that ll_rw_blk knows about this and can do something similar to the hack I posted ? Note that AFAICS nothing in drivers/scsi uses the tagging stuff in ll_rw_blk.c. blk_queue_init_tags() is only called by scsi_activate_tcq(), and nothing ever calls that (except the 53c700.c driver). So you can't just check for QUEUE_FLAG_QUEUED. Hmm, nothing in drivers/block calls it either. It's not being used at all yet ? Or am I being dense ? Mike. _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
