From: David Woodhouse <dwmw2@infradead.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
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 09:03:50 +0000 [thread overview]
Message-ID: <1227517430.26957.20.camel@macbook.infradead.org> (raw)
In-Reply-To: <1227480776.25499.3.camel@localhost.localdomain>
On Mon, 2008-11-24 at 07:52 +0900, James Bottomley wrote:
> 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.
No, I just mean writes _to the same sector_. At the moment, we happily
let those cross each other in the queue.
We do notice this situation and preserve the ordering if the two
requests cover _precisely_ the same range, but _overlapping_ writes may
happen in any order.
We should fix that, and it's only for _that_ purpose that I'm saying we
treat writes and discards as identical. And then we can drop the barrier
flag on discards.
And _then_ we can think about special cases which let us merge
non-contiguous discards.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
next prev parent reply other threads:[~2008-11-24 9:04 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
2008-11-24 9:03 ` David Woodhouse [this message]
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=1227517430.26957.20.camel@macbook.infradead.org \
--to=dwmw2@infradead.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=chris.mason@oracle.com \
--cc=djshin90@gmail.com \
--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.