> No, paging IO never acquires the main resource.
Please look at CcFlushCache() callback in FASTFAT sample - this is exactly what it does, and ,apparently,
AcquireForModWrite() callback does the same. Once lazy writer never increases valid data length, it just doest not need it…
>but lazy writer may not, because, unlike Mapped Page Writer , it is never a
>top-level component.
No, because of the other thing - the very notion of VDL. Data beyound VDL cannot be
flushed by lazy-writer, this is the definition of in-memory VDL as used by FAT
Don’t confuse the reason with consequence - data beoynd VDL may be flushed by anyone who happens to be top-level component., but once lazy writer is never the one, it cannot do it…
> Let’s concentrate on the last 3 ones - they all do write, and, therefore, unless
>paging IO is synchronized by the Memory Manager, they all have to acquire the
>main resource exclusively.
Why? Why serialize writes to some potentially huge file stream? Just imagine serializing
writes to an Oracle database sitting on hardware RAID.
…
>writes/reads to the same byte range of the file, because MM will serialize it with
>other paging reads/writes to a given byte range???
No, it will not.
My logic stands as following (in fact, it looks like I am just attempting to answer my own question and to convince myself that I am right).
Although the same mapped file range may have multiple views, all these view are backed up by the same physical pages. Therefore, in order to serialize reads and writes to any given range of a file,
all that MM has to do is to serialize pages, i.e ensure that when multiple page faults to the same range
occur or multiple requests to flush the same page to the disk get made, only one of them can actually result in writing to the disk or updating the cache. The only one who can do it is MM itself - after all, neither FSD nor Cc has control over pages that individual processes have mapped into their address spaces, i.e.
they cannot control either loading pages to RAM (because handling page faults is MM’s responsibility) or flushing them to the disk with FlushViewOfFile() (because MM is the only one who knows whether a given page has been modified and needs to be written to the disk or whether it can just get discarded because the calling process has not modified it).Therefore, serializing multiple paging read vs other paging reads and paging writes vs other paging writes to the same range has to be Memory Manager’s responsibility - no one else can be responsible for it
In order to get flushed to the disk, a page has to be physically resident in RAM, and, hence, just cannot cause a page fault. The only reason why paging read may be made is a page fault that may be caused either by application/driver that reads memory-mapped file, or by Cc upon reading data from the disk to the cache. The same page cannot be both resident and non-resident in RAM at the same time, can it ??? Therefore, paging reads and writes to the same range are mutually exclusive.
In other words, the conclusion that I made is that FSD does not need to serialize paging IO - the only reason why paging IO may acquire any resource is related to file length and valid data size, rather than
to serializing paging IO operations with one another…
Anton Bassov
how long it took to