[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: openldap.git branch mdb.master updated. 3630066843b7ca6b2cd12911d3e2fe3314cd4549
- To: openldap-commit2devel@OpenLDAP.org
- Subject: Re: openldap.git branch mdb.master updated. 3630066843b7ca6b2cd12911d3e2fe3314cd4549
- From: Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no>
- Date: Sat, 02 Aug 2014 18:17:06 +0200
- In-reply-to: <E1XBDFI-0004ve-22@euler.openldap.org>
- References: <E1XBDFI-0004ve-22@euler.openldap.org>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
On 27/07/14 03:27, openldap-commit2devel@OpenLDAP.org wrote:
commit 3630066843b7ca6b2cd12911d3e2fe3314cd4549
Author: Howard Chu <hyc@symas.com>
Date: Sat Jul 26 18:16:02 2014 -0700
Fix MIPS cache coherency on Linux
MIPS chips require manual control of on-chip caches. The cacheflush
syscall being used here only exists on MIPS Linux, other OSs will
require revisiting.
I may be guessing wrong what's going on here, but anyway:
CACHEFLUSH looks like it belongs before setting me_txns->mti_txnid
which tells other threads/processes to use the new metapage.
If so, MDB_NOLOCK may be in trouble since it uses pick_meta()
instead of mti_txnid. Should there be a separate CACHEFLUSH after
writing the datapages if MDB_NOLOCK, and the current CACHEFLUSH
should just flush the metapages?
Does the code contradict this comment above, or is it about
something else?
/* Memory ordering issues are irrelevant ... */
--
Hallvard