linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: Mark Lord <liml@rtr.ca>
Cc: Tejun Heo <htejun@gmail.com>,
	alan@lxorguk.ukuu.org.uk, linux-ide@vger.kernel.org
Subject: Re: Polling (was Re: [PATCHSET 2/2] implement PMP support, take 6)
Date: Fri, 28 Sep 2007 11:36:13 -0400	[thread overview]
Message-ID: <46FD1F6D.5060805@garzik.org> (raw)
In-Reply-To: <46FD0D9E.7040808@rtr.ca>

Mark Lord wrote:
> Jeff Garzik wrote:
> ..
>> As such, polling is simply an outmoded concept.  It does not make 
>> sense on new hardware, and forcing design decisions down that path 
>> only lead to a cascade of similar design decisions -- pmp_read polling 
>> being just one example of such a result.
> 
> A related tangent here, but I wonder if someday we might consider
> something like NAPI for libata.  Our I/O rates can far exceed those of the
> network stack, and there polling (NAPI) has helped quite a bit.

I certainly think about these issues each time I write a new storage 
driver, given that most new hardware has interrupt mitigation/coalescing 
capability built into it -- in AHCI's case, at my urging.

Storage is a different profile, with quite a bit few interrupts.

Storage interrupt rates are way, way below that of networking.  Ethernet 
is basically forced to deal with an interrupt event every 1K.  By 
design, storage gathers up as much I/O as possible, such that each 
interrupt could be completing 128K, 512K, 1MB or more.

Finally, for storage I/O workloads with lots of smaller I/Os, those 
workloads are often seek-heavy, where any interrupt overhead is few and 
far between, while you're waiting on your slow disk to seek.  You 
/don't/ want to be polling for long milliseconds, waiting for a seek. 
That's a good way to increase your CPU usage, rather than decrease it.

So, there just hasn't been a real need so far.  If interrupt overhead 
becomes an issue, my first step would be to start programming the 
interrupt coalescing hardware that comes in modern SATA controllers.

PCI MSI, found on all new controllers, tends to mitigate interrupt 
overhead even further.


> But our data behaviour is mostly synchronous, whereas network stuff is more
> asynchronous.   But still, with multiple drives all using NCQ on a port,
> a polled interface option might give higher throughput and lower CPU 
> loading.

There are definitely options worth exploring.  And with full ports all 
doing NCQ, you certainly have a lot of events to deal with.

	Jeff



  reply	other threads:[~2007-09-28 15:36 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-23  4:19 [PATCHSET 2/2] implement PMP support, take 6 Tejun Heo
2007-09-23  4:19 ` [PATCH 01/10] libata-pmp: update ata_eh_reset() for PMP Tejun Heo
2007-09-23  4:19 ` [PATCH 03/10] libata-pmp: hook PMP support and enable it Tejun Heo
2007-09-23  4:19 ` [PATCH 04/10] libata-pmp: extend ACPI support to cover PMP Tejun Heo
2007-09-23  4:19 ` [PATCH 06/10] sata_sil24: implement PMP support Tejun Heo
2007-09-23  4:19 ` [PATCH 07/10] sata_sil24: implement PORT_RST Tejun Heo
2007-09-23  4:19 ` [PATCH 02/10] libata-pmp: implement Port Multiplier support Tejun Heo
2007-09-23  4:19 ` [PATCH 05/10] libata-pmp: implement qc_defer for command switching PMP support Tejun Heo
2007-09-23  4:19 ` [PATCH 08/10] ahci: implement " Tejun Heo
2007-09-23  4:19 ` [PATCH 09/10] ahci: move host flags over to pi.private_data Tejun Heo
2007-09-23  4:19 ` [PATCH 10/10] ahci: implement AHCI_HFLAG_NO_PMP Tejun Heo
2007-09-26  2:09 ` Polling (was Re: [PATCHSET 2/2] implement PMP support, take 6) Jeff Garzik
2007-09-26  2:12   ` Jeff Garzik
2007-09-26  8:41   ` Tejun Heo
2007-09-28 12:10     ` Tejun Heo
2007-09-28 13:54     ` Jeff Garzik
2007-09-28 14:18       ` Tejun Heo
2007-09-28 14:57         ` Alan Cox
2007-09-28 15:20           ` Jeff Garzik
2007-09-28 15:43             ` Alan Cox
2007-09-28 15:40               ` Jeff Garzik
2007-09-28 20:00                 ` Mark Lord
2007-09-29  1:49                   ` Jeff Garzik
2007-09-29  3:29                   ` Jeff Garzik
2007-09-29  4:58                     ` Andrew Morton
2007-09-29  5:09                       ` Jeff Garzik
2007-09-29 16:51                     ` Greg Freemyer
2007-09-29 20:56                     ` Alan Cox
2007-10-01 12:28                       ` Jeff Garzik
2007-09-28 15:22         ` Jeff Garzik
2007-09-28 16:48           ` Tejun Heo
2007-09-28 20:02             ` Mark Lord
2007-09-28 20:25               ` Bartlomiej Zolnierkiewicz
2007-09-28 21:03               ` Alan Cox
2007-09-29  1:43                 ` Jeff Garzik
2007-09-29  5:24                   ` Tejun Heo
2007-10-01 13:31                     ` Jeff Garzik
2007-10-02  0:11                       ` Tejun Heo
2007-10-02 14:25                       ` Alan Cox
2007-10-02 14:30                         ` Jeff Garzik
2007-09-29 12:32                   ` Mark Lord
2007-10-01 12:38                     ` Jeff Garzik
2007-10-02  0:12                       ` Tejun Heo
2007-10-02 12:56                         ` Jeff Garzik
2007-10-02 13:06                           ` Mark Lord
2007-10-02 13:30                             ` Jeff Garzik
2007-10-06 22:02                               ` Tejun Heo
2007-10-09  2:09                                 ` Jeff Garzik
2007-10-09  6:54                                   ` Tejun Heo
2007-09-28 14:20   ` Mark Lord
2007-09-28 15:36     ` Jeff Garzik [this message]
2007-09-28 15:55       ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46FD1F6D.5060805@garzik.org \
    --to=jeff@garzik.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=htejun@gmail.com \
    --cc=liml@rtr.ca \
    --cc=linux-ide@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).