Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
We guarantee the ordering by making discard requests be soft barriers.
Posted Aug 15, 2008 9:34 UTC (Fri) by pjm (subscriber, #2080)
What am I missing? Jon Corbet's article and seanyoung's implementation and possibly willy's
comment above suggest that these trim/punch/discard/... requests are somehow very special in
their reordering requirements, whereas it seems to me that a discard is just the same as a
write: the existing code mustn't reorder any writes to a given block, and the new code mustn't
reorder any write-or-discard requests to a given block. This shouldn't require any more
barriers or speed penalty than we already have for writes.
(The only difference is that one might use *looser* requirements for reordering discards and
reads for a given block, depending on the semantics of reading a discarded block.)
Posted Aug 15, 2008 14:54 UTC (Fri) by willy (subscriber, #9762)
This was already discussed in the email thread ... overlapping writes are already serialised
by the page lock. Discard doesn't have a page to lock, so you can't rely on this.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds