From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Lord Subject: Re: [PATCH 09/13] sata_mv ncq Use DMA memory pools for hardware memory tables Date: Wed, 30 Jan 2008 22:59:16 -0500 Message-ID: <47A14794.5070507@rtr.ca> References: <479BC217.60709@rtr.ca> <479BC31D.1050206@rtr.ca> <479F5E1F.8030508@pobox.com> <479F6F40.7040401@rtr.ca> <47A04954.7010306@pobox.com> <47A0A875.1070203@rtr.ca> <47A0AF1F.1070609@pobox.com> <47A0B18C.1060300@rtr.ca> <47A0B7B4.9080502@pobox.com> <47A0C8AB.9050505@rtr.ca> <47A13F28.7050001@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from rtr.ca ([76.10.145.34]:1931 "EHLO mail.rtr.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752758AbYAaD7T (ORCPT ); Wed, 30 Jan 2008 22:59:19 -0500 In-Reply-To: <47A13F28.7050001@gmail.com> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Tejun Heo Cc: Jeff Garzik , IDE/ATA development list Tejun Heo wrote: >.. > I'm skeptical about the benefit of IRQ coalescing on storage > controllers. Coalescing improves performance when there are many small > requests to complete and if you put a lot of small non-consecutive > requests to a disk, it gets really really really slow and IRQ coalescing > just doesn't matter at all. The only way to achieve high number of > completions is to issue small commands to consecutive addresses which is > just silly. In storage, high volume transfer is achieved through > request coalescing not completion coalescing and this is true for even SDDs. .. One cool thing with the Marvell cores, is that they actually implement "transaction based" IRQ coalescing, whereby a number of related I/O commands (say, all the RAID5 member commands generated by a single R/W request) can be tagged together, generating an interrupt only when they all complete (or after a timeout if something goes wrong). We don't have anything resembling an appropriate abstraction for that yet, so I doubt that we could really take advantage of it. I think one thought in general for IRQ coalescing, is that with largish storage arrays it may cut down the number of IRQ entry/exit cycles considerably under heavy load, and perhaps slightly improve L1 cache occupancy of the IRQ handler paths as well. Dunno, but it could be fun to wire it in there so we can experiment and (in)validate such theories. >>>> -- Target Mode support (interfaces yet to be defined) >>> I would assume this would be along the lines of the SCSI target mode >>> stuff. >> .. >> >> Ah, now there's a starting point. Thanks. > > It would be great if we can make a cheap SATA analyzer out of it. .. Yeah. It'll have software latency added in, but the chip really looks like it can do the analyzer job just fine. I wonder if any of the existing analyzer products already use these chips.. .. > How many devices with working TCQ support are out there? Early raptors? .. Raptors, everything ever made by Hitachi, some Maxtor, some Seagate (I think), and even the odd Western Digital drive. And in the PATA space, there were WD and IBM/Hitachi drives with it. The PDC ADMA and QStor chips were designed for TCQ (and NCQ for QStor). Still though, I don't think it's a huge priority, since all modern drives now implement NCQ when it matters. Cheers