linux-kernel - Re: about TRIM/DISCARD support and barriers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 24 Nov 2008 18:52:45 +0000
From:	David Woodhouse <dwmw2@...radead.org>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	Matthew Wilcox <matthew@....cx>, Tejun Heo <teheo@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Nick Piggin <npiggin@...e.de>,
	Jens Axboe <jens.axboe@...cle.com>,
	IDE/ATA development list <linux-ide@...r.kernel.org>,
	Jeff Garzik <jeff@...zik.org>,
	Dongjun Shin <djshin90@...il.com>, chris.mason@...cle.com
Subject: Re: about TRIM/DISCARD support and barriers

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@...el.com                              Intel Corporation

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