Re: about TRIM/DISCARD support and barriers

From: David Woodhouse
Date: Mon Nov 24 2008 - 13:53:04 EST


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@xxxxxxxxx Intel Corporation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/