All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: Boaz Harrosh <bharrosh@panasas.com>
Cc: Ric Wheeler <ricwheeler@gmail.com>,
	Matthew Wilcox <matthew@wil.cx>,
	linux-scsi@vger.kernel.org
Subject: Re: [DO NOT APPLY] sd take advantage of rotation speed
Date: Wed, 25 Jun 2008 18:57:59 +0200	[thread overview]
Message-ID: <20080625165759.GC20851@kernel.dk> (raw)
In-Reply-To: <48627184.9010609@panasas.com>

On Wed, Jun 25 2008, Boaz Harrosh wrote:
> Ric Wheeler wrote:
> > Jens Axboe wrote:
> >> On Thu, Jun 19 2008, Matthew Wilcox wrote:
> >>   
> >>> Use the noop elevator by default for drives that do not spin
> >>>
> >>> [Not for applying]
> >>>
> >>> SSDs do not benefit from the elevator.  It just wastes precious CPU cycles.
> >>> By selecting the noop elevator by default, we can shave a few microseconds
> >>> off each IO.
> >>>
> >>> I've brazenly stolen sd_vpd_inquiry from mkp's patch here:
> >>>
> >>> http://marc.info/?l=linux-scsi&m=121264354724277&w=2
> >>>
> >>> No need to have two copies of that ... but this will conflict with his code.
> >>>
> >>> On to the self-criticism:
> >>>
> >>> I don't intend the final version of this patch to include a printk for
> >>> the RPM or even a printk to say we switched IO elevator.  I think we're
> >>> too verbose in SCSI as it is.
> >>>
> >>> I think there's an opportunity to improve sd_vpd_inquiry() to remove
> >>> some of the duplicate code between sd_set_elevator() and sd_block_limits,
> >>> but it's not terribly important.
> >>>
> >>> The switching of the elevators isn't particularly nice.  I assume that
> >>> elevator_init("noop") cannot fail, which isn't true.  It would be nice
> >>> to use the #if 0 block instead, but that causes a null ptr dereference
> >>> inside sysfs -- I suspect something isn't set up correctly.
> >>>     
> >> I disagree with this approach. For now, lets just add a queue flag that
> >> says the device doesn't have a seek penalty and let the io schedulers do
> >> what they need to avoid that (it'd be a one-liner change to cfq and as).
> >> There's more to io scheduling than just seek reduction, so this is the
> >> wrong direction to take imo.
> >>
> >>   
> > Very true - you still will get a significant win by coalescing IO's (say 
> > for example, to do larger, aligned writes to flash devices).
> > 
> > ric
> > 
> And to not let HUGE writers hug the machine. A scheduler ...

Precisely, merging and fairness is a big part of it. Plus, doing this in
sd is just a blatant layer violation.

-- 
Jens Axboe


  reply	other threads:[~2008-06-25 16:58 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-19 16:03 [DO NOT APPLY] sd take advantage of rotation speed Matthew Wilcox
2008-06-19 17:12 ` Mike Anderson
2008-06-19 18:10   ` Matthew Wilcox
2008-06-22 12:16 ` Boaz Harrosh
2008-06-22 13:19   ` Matthew Wilcox
2008-06-22 13:27     ` Boaz Harrosh
2008-06-22 13:38 ` James Bottomley
2008-06-22 14:03   ` Matthew Wilcox
2008-06-22 14:41     ` Martin K. Petersen
2008-06-22 18:44       ` Matthew Wilcox
2008-06-25  2:06         ` Martin K. Petersen
2008-06-22 17:26     ` James Bottomley
2008-06-25 13:47 ` Jens Axboe
2008-06-25 13:57   ` Jens Axboe
2008-06-25 14:24   ` Ric Wheeler
2008-06-25 16:25     ` Boaz Harrosh
2008-06-25 16:57       ` Jens Axboe [this message]
2008-06-25 17:20         ` Matthew Wilcox
2008-06-25 17:26           ` Jens Axboe
2008-06-25 17:34             ` Matthew Wilcox
2008-06-25 17:43               ` James Bottomley
2008-06-25 17:53                 ` Matthew Wilcox
2008-06-25 18:01                   ` Jens Axboe
2008-06-25 18:06                   ` James Bottomley
2008-06-25 17:59               ` Jens Axboe
2008-06-25 18:06             ` Martin K. Petersen
2008-06-25 18:12               ` Jens Axboe
2008-07-28 13:36               ` Ric Wheeler
2008-07-28 14:10                 ` James Bottomley
2008-07-28 14:31                 ` Martin K. Petersen
2008-07-31 21:00                   ` Grant Grundler
2008-07-31 21:19                     ` Andrew Patterson
2008-07-31 22:26                     ` Ric Wheeler
2008-07-31 23:44                       ` Grant Grundler

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=20080625165759.GC20851@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=bharrosh@panasas.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=ricwheeler@gmail.com \
    /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.