[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openldap-devel
Subject:    MIPS cachesync (was: openldap.git branch mdb.master updated. 3630066843b7ca6b2cd12911d3e2fe3314cd454
From:       Hallvard Breien Furuseth <h.b.furuseth () usit ! uio ! no>
Date:       2014-08-04 1:35:43
Message-ID: 53DEE36F.8060904 () usit ! uio ! no
[Download RAW message or body]

Should have changed the Subject: before.  Anyway:

On 02/08/14 23:28, Howard Chu wrote:
> Hallvard Breien Furuseth wrote:
>> On 02/08/14 22:31, Howard Chu wrote:
>>> Note that this is invalidating
>>> an on-chip data cache which is typically only 32KB or so. It has nothing
>>> to do with flushing the buffer cache. ("flush" is a misnomer, but that's
>>> what the syscall is called.)
>>
>> OK, but apparently it's still a cache which can include
>> data from both metapages and datapages.
>
> The thing is, it will only include *old* data from the meta pages or
> data pages. Because nothing that was updated by write() will be visible
> to the chip (thru the mmap) until the on-chip data cache is invalidated.
> And all of that old data will be self-consistent because until the
> metapage update is visible, nobody will go looking for any of the new
> datapages.

Why so?  A busy machine throws data out of caches to make room for
other data.  Some other program could presumably cause it to throw
out the old metapage version, exposing the new uncached version,
while and old version of a datapage is still cached.

Unless this is a fully associative LRU cache, so it always throws
out the oldest pages first, and no mdb_copy process just read the
cached datapage and thus refreshed it in the cache.


I remain suspicious of cacheflush(metapage and its datapages) in
one call, instead of cacheflush(datapges) before write(metapage).

-- 
Hallvard



[prev in list] [next in list] [prev in thread] [next in thread]