On Tue, Jun 20, 2000 at 11:51:23AM -0700 Daniel Lovinger (xxxxx@Exchange.Microsoft.com) wrote:
} Subject: [ntfsd] RE: very stuck with a bug - very long and involved
hmmm. your comment about changes going forward brings up an important
question …
} Noncached IO goes to media, and is distinct from write-through. If the
} file is cached as noncached IO is proceeding, though, we must
} flush/purge the cached section overhead - and this is irrespective of
} VDL. At Windows 2000, and you will see this in FAT’s write path, there
} is no synchronization to prevent pagefaults from racing with the
} noncached write (which may extend VDL, but it doesn’t matter) *after*
} the flush/purge has occurred. This was very much by design - the
} decision was to avoid introducing serialization and leave this as a case
} for the application to serialize. Note the required flush/purge: mixing
} noncached write with cached operations is not cheap.
}
} Due to some interesting irreconcilable cases this has been re-evaluated
} … we will be forcing coherency as of Whistler. If you look at FAT, the
} change suggests itself - continue holding paging IO exclusive until the
} noncached write is complete.
are you going to force coherency between file mappings and uncached i/o
as well? if so, will Microsoft be adding mechanisms to allow pages in
a user mapping to be purged?
my understanding is that the current design of the memory manager makes
this impractical.
cheers,
craig.
–
{apple,amdahl}!veritas!craig xxxxx@veritas.com
(415) 668-3564 (h) (650) 335-8520 (w)
> are you going to force coherency between file mappings and uncached
i/o
as well? if so, will Microsoft be adding mechanisms to allow pages in
a user mapping to be purged?
my understanding is that the current design of the memory manager
makes
this impractical.
Yes, it does - there are no back references to the user mappings. The
presence of things such as MDLs would also complicate (now, there is an
understatement) a guarantee that a purge would work.
RE: [ntfsd] mapped files versus non-cached i/o (was RE: very stuck with a
bug - very long and involved)>> my understanding is that the current design
of the memory manager makes >> this impractical.
Yes, it does - there are no back references to the user mappings. The
presence of things such as MDLs would also complicate (now, there is an
understatement) a guarantee that a purge would work.
Is it possible at all to implement mapped file purge in any MM design
without scanning the PTE tables of all processes in the system?
Max
On Tue, Jun 20, 2000 at 05:45:22PM -0700 Daniel Lovinger (xxxxx@Exchange.Microsoft.com) wrote:
} Subject: [ntfsd] RE: mapped files versus non-cached i/o (was RE: very stuck with a bug - very long and involved)
} > are you going to force coherency between file mappings and uncached
} i/o
} > as well? if so, will Microsoft be adding mechanisms to allow pages in
} > a user mapping to be purged?
} >
} > my understanding is that the current design of the memory manager
} makes
} > this impractical.
}
} Yes, it does - there are no back references to the user mappings. The
} presence of things such as MDLs would also complicate (now, there is an
} understatement) a guarantee that a purge would work.
hmm. OK. but if you’re not going to provide coherence between file
mappings and uncached i/o, why go to the effort of providing coherence
between cached i/o and uncached i/o?
it seems like you’re just going to burn additional CPU for uncached
i/o. this seems to run counter to the pragmatic decision that the
designers of NT made to emphasize performance over correctness (for
some definition of `correctness’ – clearly if you define uncached i/o
to be incoherent then having it be incoherent is correct).
cheers,
craig.
–
{apple,amdahl}!veritas!craig xxxxx@veritas.com
(415) 668-3564 (h) (650) 335-8520 (w)
> hmm. OK. but if you’re not going to provide coherence between file
mappings and uncached i/o, why go to the effort of providing coherence
between cached i/o and uncached i/o?
There is a case involving fileservers where the previous decision was
not nearly so clear cut.
it seems like you’re just going to burn additional CPU for uncached
i/o. this seems to run counter to the pragmatic decision that the
designers of NT made to emphasize performance over correctness (for
some definition of `correctness’ – clearly if you define uncached i/o
to be incoherent then having it be incoherent is correct).
This was pretty easy - the synchronization is only picked up if/when
required. Note that this has *not* shipped yet, and is subject to change
(etc. etc.).