All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org,
	Tejun Heo <htejun@gmail.com>
Subject: Re: libata / scsi separation
Date: Tue, 9 Dec 2008 20:37:08 -0700	[thread overview]
Message-ID: <20081210033708.GV25548@parisc-linux.org> (raw)
In-Reply-To: <1228862287.3263.52.camel@localhost.localdomain>

On Tue, Dec 09, 2008 at 04:38:07PM -0600, James Bottomley wrote:
> On Tue, 2008-12-09 at 15:21 -0700, Matthew Wilcox wrote:
> > The performance penalty is certainly measurable.  It's about 1 microsecond
> > per request extra to go from userspace -> scsi -> libata -> driver
> > than it is to go from userspace -> scsi -> driver.  If you issue 400
> > commands per second (as you might do with a 15k RPM SCSI drive), that's
> > 400 microseconds.  If you issue 10,000 commands per second (as you might
> > do with an SSD), that's 10ms of additional CPU time spent in the kernel
> > per second (or 1%).
> 
> Um, not quite.  What you're talking about is increased latency.  It's

Tsk.  I was quite clear I wasn't talking about latency or bandwidth.  I
was talking about the amount of CPU used to keep a device busy.

> not cumulative because we use TCQ (well mostly).  The question is really
> how it impacts the benchmarks, which are mostly throughput based (and
> really, our block layer trades latency for throughput anyway, so it's
> not clear what the impact really is).

If 1% of CPU is being used by the kernel, that's 1% of CPU not available
for the user application (or alternatively an extra centisecond the CPU
could be in a low-power state if you're not CPU-bound).

> > (OK, I haven't measured the overhead of the *SCSI* layer, I've measured
> > the overhead of the *libata* layer.  I think the point here is that you
> > can't measure the difference at a macro level unless you're sending a
> > lot of commands.)
> 
> Perhaps one of the things we should agree on is exactly how we want to
> measure things like this.  Making the layering thinner for less latency
> is usually good ... unless there are other tradeoffs.  I think not
> forcing ata disks to go through SCSI will probably be tradeoff free, but
> we need to make sure it is.

That would certainly be a good idea.  I don't think we have a consensus
about what we should be measuring yet ;-)

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

  reply	other threads:[~2008-12-10  3:37 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-03  1:38 [PATCH] remove ide-scsi FUJITA Tomonori
2008-12-03 10:06 ` Christoph Hellwig
2008-12-03 13:31   ` Willem Riede
2008-12-03 13:55     ` Matthew Wilcox
2008-12-03 14:02       ` Alan Cox
2008-12-03 15:09   ` James Bottomley
2008-12-06  6:12     ` Pete Zaitcev
2008-12-06 14:06       ` Bartlomiej Zolnierkiewicz
2008-12-06 14:51     ` Bartlomiej Zolnierkiewicz
2008-12-06 15:06       ` Alan Cox
2008-12-06 16:29         ` Bartlomiej Zolnierkiewicz
2008-12-06 15:25       ` Willem Riede
2008-12-06 15:59         ` Bartlomiej Zolnierkiewicz
2008-12-06 17:00       ` Dan Noé
2008-12-06 21:41         ` Bartlomiej Zolnierkiewicz
2008-12-06 22:24           ` Alan Cox
2008-12-06 22:52             ` Sergei Shtylyov
2008-12-06 23:02               ` Alan Cox
2008-12-06 23:19                 ` Sergei Shtylyov
2008-12-06 23:32                   ` Alan Cox
2008-12-07  0:08                     ` Sergei Shtylyov
2008-12-07 11:40                       ` Alan Cox
2008-12-07 14:46                         ` Sergei Shtylyov
2008-12-07 15:04                   ` James Bottomley
2008-12-07 15:21                     ` Sergei Shtylyov
2008-12-09 22:21                     ` libata / scsi separation Matthew Wilcox
2008-12-09 22:38                       ` James Bottomley
2008-12-10  3:37                         ` Matthew Wilcox [this message]
2008-12-10  1:54                       ` Tejun Heo
2008-12-10  2:29                         ` Grant Grundler
2008-12-10  2:47                           ` Tejun Heo
2008-12-10  3:23                             ` Grant Grundler
2008-12-10  3:44                               ` Tejun Heo
2008-12-10 15:24                                 ` Matthew Wilcox
2008-12-10 15:33                                   ` Tejun Heo
2008-12-10 16:01                                     ` Matthew Wilcox
2008-12-10 17:11                                     ` Grant Grundler
2008-12-10 17:21                                   ` Grant Grundler
2008-12-07  0:19                 ` [PATCH] remove ide-scsi Sergei Shtylyov
2008-12-07  9:59                   ` Sergei Shtylyov
2008-12-07 10:41                 ` Sergei Shtylyov
2008-12-09 21:41                 ` Matthew Wilcox
2008-12-10 17:46                   ` Sergei Shtylyov
2008-12-06 23:28               ` Jeff Garzik
2008-12-06 23:42                 ` Sergei Shtylyov
2008-12-06 23:48                   ` Jeff Garzik
2008-12-07  3:36                     ` Yinghai Lu
2008-12-07  4:17                       ` Jeff Garzik
2008-12-07  5:07                         ` Yinghai Lu
2008-12-07 11:00                           ` Sergei Shtylyov
2008-12-09 19:59                         ` Mark Lord
2008-12-09 20:07                           ` Jeff Garzik
2008-12-09 21:04                             ` James Bottomley
2008-12-06 23:45                 ` Bartlomiej Zolnierkiewicz
2008-12-06 23:50                   ` Jeff Garzik
2008-12-06 23:40             ` Bartlomiej Zolnierkiewicz
2008-12-06 23:51               ` Alan Cox
2008-12-07  0:56                 ` Bartlomiej Zolnierkiewicz
2008-12-07  1:14                   ` Alan Cox
2008-12-07 10:32                     ` Sergei Shtylyov
2008-12-06 23:51               ` Jeff Garzik
2008-12-06 22:33           ` Al Viro
2008-12-06 23:13             ` Bartlomiej Zolnierkiewicz
2008-12-06 23:17             ` Willem Riede
2008-12-07  0:09               ` Al Viro

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=20081210033708.GV25548@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=htejun@gmail.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-scsi@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.