diff --git a/docs/behind_scenes/vulkan_support.rst b/docs/behind_scenes/vulkan_support.rst
index 6820cb7bc..0ad234504 100644
--- a/docs/behind_scenes/vulkan_support.rst
+++ b/docs/behind_scenes/vulkan_support.rst
@@ -24,7 +24,7 @@ Performance notes
 
 Vulkan is intended as a high-performance low CPU overhead API, and RenderDoc strives to maintain that performance contract at a reasonable level. While some overhead is inevitable RenderDoc aims to have no locks on the 'hot path' of command buffer recording, minimal or no allocation, and in general to have low performance overhead while not capturing.
 
-Some patterns of access are more or less conducive to good performance on RenderDoc, so if you are having trouble with slow capture, large memory/disk overhead or slow replay you might want to try eliminating use of persistent maps of memory from coherent heaps - you can use ``vkFlushMappedMemoryRanges`` to emulate non-coherent heaps and RenderDoc will take advantage of that, or you can use non-persistent maps.
+Some patterns of access are more or less conducive to good performance on RenderDoc, so if you are having trouble with slow capture, large memory/disk overhead or slow replay you might want to try eliminating use of persistent maps of memory from coherent heaps by mapping and unmapping them around changes, or reduce the number of submits you make while you have coherent memory persistently mapped.
 
 Likewise try to avoid making very large memory allocations in the range of 1GB and above. By its nature RenderDoc must save one or more copies of memory allocations to enable proper capture, so having allocations limited to only a few 100s of megabytes can help gain granularity of management and limit the memory overhead RenderDoc adds. There may be optimisation of this in future on RenderDoc's side but there are no easy guarantees.
 
diff --git a/renderdoc/driver/vulkan/vk_resources.h b/renderdoc/driver/vulkan/vk_resources.h
index 31bacf6df..799b5f1e3 100644
--- a/renderdoc/driver/vulkan/vk_resources.h
+++ b/renderdoc/driver/vulkan/vk_resources.h
@@ -1136,7 +1136,6 @@ struct MemMapState
   VkDeviceSize mapOffset = 0, mapSize = 0;
   bool dedicated = false;
   bool needRefData = false;
-  bool mapFlushed = false;
   bool mapCoherent = false;
   bool readbackOnGPU = false;
   // pointer to base of memory, may not be valid until after mapOffset bytes
diff --git a/renderdoc/driver/vulkan/wrappers/vk_queue_funcs.cpp b/renderdoc/driver/vulkan/wrappers/vk_queue_funcs.cpp
index cba2ff9a2..0d191aecd 100644
--- a/renderdoc/driver/vulkan/wrappers/vk_queue_funcs.cpp
+++ b/renderdoc/driver/vulkan/wrappers/vk_queue_funcs.cpp
@@ -1011,7 +1011,7 @@ void WrappedVulkan::CaptureQueueSubmit(VkQueue queue,
       SCOPED_LOCK(state.mrLock);
 
       // potential persistent map
-      if(state.mapCoherent && state.mappedPtr && !state.mapFlushed)
+      if(state.mapCoherent && state.mappedPtr)
       {
         // only need to flush memory that could affect this submitted batch of work, or if there are
         // BDA buffers bound (as we can't track those!)
diff --git a/renderdoc/driver/vulkan/wrappers/vk_resource_funcs.cpp b/renderdoc/driver/vulkan/wrappers/vk_resource_funcs.cpp
index 419edf521..9e081e493 100644
--- a/renderdoc/driver/vulkan/wrappers/vk_resource_funcs.cpp
+++ b/renderdoc/driver/vulkan/wrappers/vk_resource_funcs.cpp
@@ -797,7 +797,6 @@ VkResult WrappedVulkan::vkMapMemory(VkDevice device, VkDeviceMemory mem, VkDevic
       state.mapOffset = offset;
       state.mapSize = size == VK_WHOLE_SIZE ? (memrecord->Length - offset)
                                             : RDCMIN(memrecord->Length - offset, size);
-      state.mapFlushed = false;
 
       *ppData = realData + misalignedOffset;
 
@@ -1185,9 +1184,6 @@ void WrappedVulkan::InternalFlushMemoryRange(VkDevice device, const VkMappedMemo
 
   MemMapState *state = record->memMapState;
 
-  if(!internalFlush)
-    state->mapFlushed = true;
-
   if(state->mappedPtr == NULL)
   {
     RDCERR("Flushing memory %s that isn't currently mapped", ToStr(memid).c_str());