All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc MERLIN <marc@merlins.org>
To: "Lukáš Czerner" <lczerner@redhat.com>
Cc: tytso@mit.edu, linux-ext4@vger.kernel.org, axboe@kernel.dk,
	Milan Broz <mbroz@redhat.com>
Subject: Re: du -s src is a lot slower on SSD than spinning disk in the same laptop
Date: Wed, 25 Jul 2012 16:38:59 -0700	[thread overview]
Message-ID: <20120725233859.GA6752@merlins.org> (raw)
In-Reply-To: <alpine.LFD.2.00.1207252023080.4340@(none)>

On Wed, Jul 25, 2012 at 08:40:28PM +0200, Lukáš Czerner wrote:
> yesterday Milan Broz pointed me to the other problem of yours where
> by reading from dm_crypt target on the SSD was much slower than on
> the spinning disk. I am not sure if he already shared some
> information he managed to gather, but we saw that reading from SSD
> was much slower probably because reads were divided into tons of
> small (page size) bios as opposed to bigger chunks on spinning
> disk.
 
Yes, indeed. To make things simpler, I'm not using dmcrypt here.

> This is probably the same reason here. The reason is most likely
> that we handle SSD differently than spinning disk (turn off
> elevator, different io scheduler and possibly other things I am not
> aware of). Also IIRC bio merging should be less "aggressive" on SSD
> than spinning disk (or maybe even turned off?), because SSD should
> supposedly handle much more iops than than spinning drive, hence
> waiting for a merge might slow things down. However in this case it
> seems to have quite opposite effect for some reason.
> 
> You may try to convince kernel to treat your SSD as rotational disk
> by:
> 
> echo 1 > /sys/block/sda/queue/rotational
> and see if it improves things.

Actually I had done that, along with making the readahead 8K change, but
that didn't help:

gandalfthegreat:/mnt/mnt2# time du -sh src/
519M	src/
real	0m12.176s
gandalfthegreat:/mnt/mnt2# df -h .
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        25G  3.0G   21G  13% /mnt/mnt2
gandalfthegreat:/mnt/mnt2# blockdev --report /dev/sda2
RO    RA   SSZ   BSZ   StartSec            Size   Device
rw  8192   512  4096     502272     26843283456   /dev/sda2
gandalfthegreat:/mnt/mnt2# cat /sys/block/sda/queue/rotational
1
gandalfthegreat:/mnt/mnt2# 

> Unfortunately I think that there is not much we can do about this
> from the file system level. Someone from block level should
> definitely take a look at this issue. Jens ?

Ok, I just wanted to rule out that it was not a VFS issue.
If you're confident it's block level and basically having storage that is
too fast (and indeed, I just bought one of the fastest SSDs out there) is
actually causing problems that make the entire system much slower as a
result, I'm happy to take it up another list.

Where would you recommend I go with this?

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2012-07-25 23:39 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-25 15:45 du -s src is a lot slower on SSD than spinning disk in the same laptop Marc MERLIN
     [not found] ` <alpine.LFD.2.00.1207252023080.4340@(none)>
2012-07-25 23:38   ` Marc MERLIN [this message]
2012-07-26  3:32   ` Ted Ts'o
2012-07-26  3:35     ` Marc MERLIN
2012-07-26  6:54     ` Marc MERLIN
2012-08-01  5:30       ` Marc MERLIN
2012-08-01  8:18         ` Spelic
2012-08-16  7:50         ` Marc MERLIN
     [not found]           ` <502CC2A2.4010506@shiftmail.org>
2012-08-16 17:55             ` Marc MERLIN
2012-09-05 16:52               ` ext4 crash with 3.5.2 in ext4_ext_remove_space Marc MERLIN
2012-09-05 17:50                 ` Lukáš Czerner
2012-09-05 17:53                   ` Marc MERLIN
2012-09-06  4:24                   ` Marc MERLIN
2012-09-07 15:19                     ` Marc MERLIN
2012-09-07 15:39                       ` Lukáš Czerner
2012-09-07 15:51                         ` Marc MERLIN
  -- strict thread matches above, loose matches on Subject: below --
2012-01-30  0:37 brtfs on top of dmcrypt with SSD. No corruption iff write cache off? Marc MERLIN
2012-02-01 17:56 ` Chris Mason
2012-02-02  3:23   ` Marc MERLIN
2012-02-02 12:42     ` Chris Mason
2012-02-12 22:32     ` Marc MERLIN
2012-02-12 23:47       ` Milan Broz
2012-02-13  0:14         ` Marc MERLIN
2012-02-15 15:42           ` Calvin Walton
2012-02-15 16:55             ` Marc MERLIN
2012-02-15 16:59               ` Hugo Mills
2012-02-22 10:28                 ` Justin Ossevoort
2012-02-22 11:07                   ` Hugo Mills
2012-02-16  6:33           ` Chris Samuel
2012-02-18 12:33           ` Martin Steigerwald
2012-02-18 12:39           ` Martin Steigerwald
2012-02-18 12:49             ` Martin Steigerwald
2012-02-18 16:07             ` Marc MERLIN
2012-02-19  0:53               ` Clemens Eisserer
2012-07-18 18:13 ` brtfs on top of dmcrypt with SSD -> Trim or no Trim Marc MERLIN
2012-07-18 20:04   ` Fajar A. Nugraha
2012-07-18 20:37     ` Marc MERLIN
2012-07-18 21:34     ` Clemens Eisserer
2012-07-18 21:48       ` Marc MERLIN
2012-07-18 21:49   ` Martin Steigerwald
2012-07-18 22:04     ` Marc MERLIN
2012-07-19 10:40       ` Martin Steigerwald
2012-07-22 18:58       ` brtfs on top of dmcrypt with SSD -> ssd or nossd + crypt performance? Marc MERLIN
2012-07-22 19:35         ` Martin Steigerwald
2012-07-22 19:43           ` Martin Steigerwald
2012-07-22 20:44           ` Marc MERLIN
2012-07-22 22:41             ` brtfs on top of dmcrypt with SSD -> file access 5x slower than spinning disk Marc MERLIN
2012-07-23  6:42               ` How can btrfs take 23sec to stat 23K files from an SSD? Marc MERLIN
2012-07-24  7:56                 ` Martin Steigerwald
2012-07-27  4:40                   ` Marc MERLIN
2012-07-27 11:08                 ` Chris Mason
2012-07-27 18:42                   ` Marc MERLIN
2012-08-01  6:01                     ` Marc MERLIN
2012-08-01  6:08                       ` Fajar A. Nugraha
2012-08-01  6:21                         ` Marc MERLIN
2012-08-01 21:57                           ` Martin Steigerwald
2012-08-02  5:07                             ` Marc MERLIN
2012-08-02 11:18                               ` Martin Steigerwald
2012-08-02 17:39                                 ` Marc MERLIN
2012-08-02 20:20                                   ` Martin Steigerwald
2012-08-02 20:44                                     ` Marc MERLIN
2012-08-02 21:21                                       ` Martin Steigerwald
2012-08-02 21:49                                         ` Marc MERLIN
2012-08-03 18:45                                           ` Martin Steigerwald
2012-08-16  7:45                                             ` Marc MERLIN
2012-08-02 11:25                               ` Martin Steigerwald
2012-08-01  6:36                       ` Chris Samuel
2012-08-01  6:40                         ` Marc MERLIN

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=20120725233859.GA6752@merlins.org \
    --to=marc@merlins.org \
    --cc=axboe@kernel.dk \
    --cc=lczerner@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=mbroz@redhat.com \
    --cc=tytso@mit.edu \
    /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.