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 18:52:45 +0000 [thread overview]
Message-ID: <1227552765.25385.129.camel@macbook.infradead.org> (raw)
In-Reply-To: <1227552171.25499.30.camel@localhost.localdomain>
On Mon, 2008-11-24 at 13:42 -0500, James Bottomley wrote:
> On Mon, 2008-11-24 at 09:03 +0000, David Woodhouse wrote:
> > 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.
...
> It's not a bug ... but changing it might be feasible ... as long as it
> doesn't affect write performance too much (which I don't think it will),
> since it is in the critical path.
We could argue about how much sense it makes to let two writes to the
same sector actually happen in reverse order.
Especially given the fact that we actually _do_ preserve ordering in
some cases; just not in others. (We preserve ordering only if the start
and end of the duplicate writes are _precisely_ matching; if it's just
overlapping (which may well happen in the presence of merges), then this
check doesn't trigger.
But that's just semantics. Yes, changing it should be feasible. I talked
to Jens about that at the kernel summit, and we agreed that it should
probably be done.
> > And _then_ we can think about special cases which let us merge
> > non-contiguous discards.
>
> I still think that treating discards as a special command from the
> outset is the better way forwards.
They're already treated as a special command and you can special-case
them wherever you like, so I'm not entirely sure what you're suggesting.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
next prev parent reply other threads:[~2008-11-24 18:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-23 4:46 Tejun Heo
2008-11-23 7:11 ` 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
2008-11-24 18:42 ` James Bottomley
2008-11-24 18:52 ` David Woodhouse [this message]
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
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=1227552765.25385.129.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®