linux-ext4.vger.kernel.org archive mirror
 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: 19+ 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  6:01         ` How can btrfs take 23sec to stat 23K files from an SSD? Marc MERLIN
2012-08-01  6:36           ` Chris Samuel
2012-08-01  6:40             ` Marc MERLIN
2012-08-01  8:18         ` du -s src is a lot slower on SSD than spinning disk in the same laptop 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
     [not found] <201207222135.11159.Martin@lichtvoll.de>
     [not found] ` <20120202124241.GW16796@shiny>
     [not found]   ` <20120718220446.GB3888@merlins.org>
     [not found]     ` <20120722185848.GA10089@merlins.org>
     [not found]       ` <20120722204428.GC3925@merlins.org>
     [not found]         ` <20120722224145.GC12951@merlins.org>
     [not found]           ` <20120723064202.GB6931@merlins.org>
     [not found]             ` <20120727110835.GA6933@shiny>

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 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).