Changeset 78609 in vbox for trunk/src

Timestamp:

May 20, 2019 11:15:40 PM (6 years ago)

Author:

vboxsync

Message:

winnt/vboxsf: Don't flush and purge the cache twice on newer systems, instead do a library trick to redirect relevant imports from write.obj and read.obj to our wrappers that uses CcCoherencyFlushAndPurgeCache when possible to get better coherency between mmap regions and file content when writing and reading normally. This comes at a cost when the file has been mmapped at some point previously (or currently) and we may need to purge stuff. bugref:9172

File:

• trunk/src/VBox/Additions/WINNT/SharedFolders/driver/file.cpp (modified) (5 diffs)

trunk/src/VBox/Additions/WINNT/SharedFolders/driver/file.cpp

@@ -34 +34 @@
 
 
-/** @name Hacks for using the better CcCoherencyFlushAndPurgeCache when
- *        available (>= Windows 7) and avoid flushing+puring twice.
- *
- * We change the cache flushing and purging related imports from  the write.obj
+/** @name HACK ALERT! Using the better CcCoherencyFlushAndPurgeCache when
+ *        available (>= Windows 7) and avoid flushing+purging cache twice.
+ *
+ * We change the cache flushing and purging related imports from the write.obj
  * and read.obj files in the rdbsslib.lib to import so these gets redirected
  * here instead of going directly to ntoskrnl.  We will use
@@ -44 +44 @@
  * purging on newer systems.
  *
+ * If we don't use CcCoherencyFlushAndPurgeCache we end up not seeing newly
+ * written data in memory mappings, and similarlly not seeing data from freshly
+ * dirtied (but as yet unflushed) memory mapping pages when reading.  (Both
+ * these scenarios are tested by FsPerf --mmap.)
+ *
  * See VBoxEditCoffLib and the Makefile.kmk for the rest of the puzzle.
  *
+ * @todo investigate whether we could do it the same way as we do on linux,
+ *       where we iterrogate the cache and use cached data when memory mappings
+ *       are active.  Only troubles are:
+ *
+ *          1. Don't know how to find out whether we've got memory mappings.
+ *
+ *          2. Don't know how to detect dirty pages (we should only read
+ *             from dirty ones).
+ *
+ *       To really explore this, it would be best to introduce a caching mode
+ *       mount parameter (or something) analogous to what we have on linux.  In
+ *       the relaxed mode, we could get away with more as users could always
+ *       disable caching...
  * @{
  */
 
+/** For reads. */
 static VOID NTAPI vbsfNtReadCcFlushCache(PSECTION_OBJECT_POINTERS pSectObjPtrs, PLARGE_INTEGER poffFlush, ULONG cbFlush,
                                          PIO_STATUS_BLOCK pIos)
@@ -58 +77 @@
 }
 
+
+/**
+ * For writes with mmapping/caching section, called before the purging.
+ *
+ * This does both flushing and puring when CcCoherencyFlushAndPurgeCache is
+ * available.
+ */
 static VOID NTAPI vbsfNtWriteCcFlushCache(PSECTION_OBJECT_POINTERS pSectObjPtrs, PLARGE_INTEGER poffFlush, ULONG cbFlush,
                                           PIO_STATUS_BLOCK pIos)
@@ -68 +94 @@
 
 
+/**
+ * For writes with mmapping/caching section, called to purge after flushing.
+ *
+ * We translate this to a no-op when CcCoherencyFlushAndPurgeCache is available.
+ */
 static BOOLEAN NTAPI vbsfNtWriteCcPurgeCacheSection(PSECTION_OBJECT_POINTERS pSectObjPtrs, PLARGE_INTEGER poffPurge,ULONG cbPurge,
 #if (NTDDI_VERSION >= NTDDI_VISTA)
@@ -88 +119 @@
 
 extern "C" {
+/** This is what read.obj gets instead of __imp_CcFlushCache. */
 decltype(CcFlushCache)        *g_pfnRdFlushCache        = vbsfNtReadCcFlushCache;
+/** This is what write.obj gets instead of __imp_CcFlushCache. */
 decltype(CcFlushCache)        *g_pfnWrFlushCache        = vbsfNtWriteCcFlushCache;
+/** This is what write.obj gets instead of __imp_CcPurgeCacheSection. */
 decltype(CcPurgeCacheSection) *g_pfnWrPurgeCacheSection = vbsfNtWriteCcPurgeCacheSection;
 }