[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: MIPS cachesync

Hallvard Breien Furuseth wrote:

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.
On a busy machine the old data page will be long gone from the cache. Keep in mind that an old data page being written by a current txn cannot have been referenced by any of the previous 2 txns. 


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).




--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/