All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukas Czerner <lczerner@redhat.com>
To: "Ted Ts'o" <tytso@mit.edu>
Cc: Lukas Czerner <lczerner@redhat.com>,
	eshishki@redhat.com, jmoyer@redhat.com, rwheeler@redhat.com,
	linux-ext4@vger.kernel.org, sandeen@redhat.com
Subject: Re: Ext4: batched discard support - simplified version
Date: Mon, 26 Jul 2010 12:30:28 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LFD.2.00.1007261209310.2905@localhost> (raw)
In-Reply-To: <20100723143604.GF13090@thunk.org>

On Fri, 23 Jul 2010, Ted Ts'o wrote:

> On Wed, Jul 07, 2010 at 09:53:30AM +0200, Lukas Czerner wrote:
> > 
> > Hi all,
> > 
> > since my last post I have done some more testing with various SSD's and the
> > trend is clear. Trim performance is getting better and the performance loss
> > without trim is getting lower. So I have decided to abandon the initial idea
> > to track free blocks within some internal data structure - it takes time and
> > memory.
> 
> Do you have some numbers about how bad trim actually might be on
> various devices?  I can imagine some devices where it might be better
> (for wear levelling and better write endurance if nothing else) where
> it's better to do the trim right away instead of batching things.

Hi,

Yes, I have those numbers.

http://people.redhat.com/jmoyer/discard/ext4_batched_discard/ext4_discard.html
This page presents my test results on three different devices. I have
tested the current ext4 discard implementation (do the trim right away).
However, one tested device is still not on that page. With this
(Vendor4) device I have got only about 1.83% performance loss, which is
very good.

http://people.redhat.com/jmoyer/discard/ext4_batched_discard/ext4_ioctltrim.html
This page provides test results with my batched discard implementation.
Take those numbers with discretion, because the patch still does not
involve journaling and I have tested the "worst case" scenario, which
involves issuing FITRIM in endless loop without any sleep.

Generally the FITRIM ioctl can take from 2 seconds on fast devices to
several (2-4) minutes on very slow devices, or under heavy load.


> 
> So what I'm thinking about doing is keeping the "discard" mount option
> to mean non-batched discard.  If you want to use the explicit FITRIM
> ioctl, I don't think we need to test to see if the dicard mount option
> is set; if the user issues the ioctl, then we should do the batched
> discard, and if we don't trust the user to do that, then well, the
> ioctl should be restricted to privileged users only --- especially if
> it could take up to a minute.

I agree.

> 
> 						- Ted
> 

Thanks.

-Lukas

      parent reply	other threads:[~2010-07-26 10:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-07  7:53 Ext4: batched discard support - simplified version Lukas Czerner
2010-07-07  7:53 ` [PATCH 1/2] Add ioctl FITRIM Lukas Czerner
2010-07-07  7:53 ` [PATCH 2/2] Add batched discard support for ext4 Lukas Czerner
2010-07-14  8:33   ` Dmitry Monakhov
2010-07-14  9:40     ` Lukas Czerner
2010-07-14 10:03       ` Dmitry Monakhov
2010-07-14 11:43         ` Lukas Czerner
2010-07-23 14:36 ` Ext4: batched discard support - simplified version Ted Ts'o
2010-07-23 15:13   ` Jeff Moyer
2010-07-23 15:19     ` Ted Ts'o
2010-07-23 15:40       ` Jeff Moyer
2010-07-23 17:00         ` Ted Ts'o
2010-07-24 16:31       ` Ric Wheeler
2010-07-23 15:30     ` Greg Freemyer
2010-07-26 10:30   ` Lukas Czerner [this message]

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=alpine.LFD.2.00.1007261209310.2905@localhost \
    --to=lczerner@redhat.com \
    --cc=eshishki@redhat.com \
    --cc=jmoyer@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=rwheeler@redhat.com \
    --cc=sandeen@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.