From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Matthew Wilcox <matthew@wil.cx>, Tejun Heo <teheo@suse.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Nick Piggin <npiggin@suse.de>, Jens Axboe <jens.axboe@oracle.com>,
IDE/ATA development list <linux-ide@vger.kernel.org>,
Jeff Garzik <jeff@garzik.org>, Dongjun Shin <djshin90@gmail.com>,
chris.mason@oracle.com
Subject: Re: about TRIM/DISCARD support and barriers
Date: Mon, 24 Nov 2008 07:52:56 +0900 [thread overview]
Message-ID: <1227480776.25499.3.camel@localhost.localdomain> (raw)
In-Reply-To: <1227447584.4901.405.camel@macbook.infradead.org>
On Sun, 2008-11-23 at 13:39 +0000, David Woodhouse wrote:
> > We don't attempt to put non-contiguous ranges into a single TRIM yet.
>
> We don't even merge contiguous ranges -- I still need to fix the
> elevators to stop writes crossing writes,
I don't think we want to do that ... it's legal if the write isn't a
barrier and it will inhibit merging. That may be just fine for a SSD,
but it's not for spinning media since they get better performance out of
merged writes.
> before we can stop discards
> from also being barriers. (Discards are just writes, for the purpose of
> that conversation).
Perhaps they shouldn't be ... they have different characteristics. For
instance, a discard may cross a read or write that has no sectors in
common with it; a discard may be merged as a non contiguous range
(assuming the drive supports multiple ranges), etc.
I think it might be better to give it its own type for the elevators.
James
next prev parent reply other threads:[~2008-11-23 22:53 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-23 4:46 about TRIM/DISCARD support and barriers Tejun Heo
2008-11-23 4:46 ` Tejun Heo
2008-11-23 7:11 ` Tejun Heo
2008-11-23 7:11 ` Tejun Heo
2008-11-23 7:57 ` Tejun Heo
2008-11-23 7:57 ` Tejun Heo
2008-11-24 5:40 ` Dongjun Shin
2008-11-24 5:45 ` Tejun Heo
2008-11-24 5:57 ` James Bottomley
2008-11-23 12:35 ` Matthew Wilcox
2008-11-23 13:39 ` David Woodhouse
2008-11-23 22:52 ` James Bottomley [this message]
2008-11-24 9:03 ` David Woodhouse
2008-11-24 18:42 ` James Bottomley
2008-11-24 18:52 ` David Woodhouse
2008-11-24 18:57 ` Jens Axboe
2008-11-24 19:08 ` James Bottomley
2008-11-25 9:16 ` Jens Axboe
2008-11-24 19:09 ` James Bottomley
2008-11-25 3:28 ` Matthew Wilcox
2008-11-25 9:15 ` Jens Axboe
2008-11-24 3:01 ` Theodore Tso
2008-11-28 13:21 ` Raz Ben-Yehuda
2008-11-29 22:57 ` Tejun Heo
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=1227480776.25499.3.camel@localhost.localdomain \
--to=james.bottomley@hansenpartnership.com \
--cc=chris.mason@oracle.com \
--cc=djshin90@gmail.com \
--cc=dwmw2@infradead.org \
--cc=jeff@garzik.org \
--cc=jens.axboe@oracle.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=npiggin@suse.de \
--cc=teheo@suse.de \
/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.