Windows, NT Cache Manager - Molly Brown - Part II | Going Deep

tsilb
Hardware Geek, Multimon, Carputer

Interesting video, but it raises some questions: How does the cache manager (Cacheman?) interact with the multiple memory controllers commensurate with multi procs or multi cores? Seems the video was about to address that but kinda skipped over it like a sensitive topic or something. How does the cache manager keep track of which memory controller owns what addresses? Does it multiply the amount of buffer space or divide the existing buffer space by the number of processors?

Minh
WOOH! WOOH!

How does DMA fit in all this? Or is that something outside of this lib?

LarryOsterman

Minh wrote:
How does DMA fit in all this? Or is that something outside of this lib?

It's outside of CC. The I/O's that read data into the cache are all effectively synchronous (they're not, but paging I/O has to be on a non blocking, non paged path). DMA is just how the data gets from the disk into RAM.

LarryOsterman

tsilb wrote:
Interesting video, but it raises some questions: How does the cache manager (Cacheman?) interact with the multiple memory controllers commensurate with multi procs or multi cores? Seems the video was about to address that but kinda skipped over it like a sensitive topic or something. How does the cache manager keep track of which memory controller owns what addresses? Does it multiply the amount of buffer space or divide the existing buffer space by the number of processors?

Unless CC has been rewritten since NT4 (which IS possible, other major kernel mode components (like RDR) have been rewritten), it's irrelevant.

CC doesn't use buffers per se, instead it uses MM to map a section of the file into memory and then reads the data from the shared memory section.

Since there's only one physical address space on a multi-proc or multi-core machine, it doesn't matter. Now NUMA may change this behavior, I'm not sure how CC plays with NUMA.

codan
I didn't do it.

It was said that the cache manager's lazy writers may take ~8 seconds to flush dirty pages to disk. What measures, if any, are in place to protect unflushed cached data during power outages or hardware failures?

BinaryBoy

Excellent videos. Nice to see a low level technical one once in a while. I happen to be optimizing some code that handles multi-hundred meg and sometimes gigabyte files so seeing how things work under the hood has been very interesting and helpful.

Mike Dimmick

codan wrote:
It was said that the cache manager's lazy writers may take ~8 seconds to flush dirty pages to disk. What measures, if any, are in place to protect unflushed cached data during power outages or hardware failures?

None, for user files. If you want to force a write directly to disk, use FILE_FLAG_WRITE_THROUGH when opening the file, or call FlushFileBuffers. You need to specify FILE_FLAG_NO_BUFFERING as well if you want to be sure that the drive itself does not buffer the operation.

NTFS logs all operations it performs to filesystem metadata. It keeps track of the latest operation to affect each page of the cached metadata. The memory manager is instructed not to write modified pages (by placing them on a ModifiedNoWrite list) if the log entries for that page have not yet been written. Once the log entries are written (log entries are batched up), the pages affected by those log entries are moved onto the Modified list and can now be written by the lazy writer. If the changes don't make it to disk before the power fails, NTFS can reapply the changes at boot time by redoing the operations recorded in the log.

NTFS only guarantees that the file system is in a consistent state. It does not guarantee that the file system is in the latest recorded consistent state. If you need a stronger guarantee you need to battery-back your system or otherwise provide a backup power supply.

Longhorn is apparently to add transaction support to NTFS, partly so that user data can also be protected by logging (also so that full transactional commit/rollback semantics can be applied). This is however an opt-in feature and is likely to be a bit slower than regular disk accesses. You have to trade off speed against the slight risk of power failure.

Any greater detail is difficult to go into here. To truly understand the cache manager, you really have to understand the memory manager as well. Windows Internals 4th Edition spends 110 pages on the memory manager, and 45 pages on the cache manager. It then has 58 pages on NTFS.

Charles
Welcome Change

Memory Manager will be covered in the not too distant future in this series. Keep in mind that these videos serve as introductions to the technology and the people behind it. Books are generally really good for highly specific and detailed analysis of complex topics. Video, on the other hand, really isn't. So, Going Deep will only be able to go so far and still keep you wanting to watch!

C

kinrowan

I don't know if anyone else is interested, but I ripped the audio of this video (with Robert's kind permission) and posted it on OurMedia. You can find it at http://www.ourmedia.org/node/10031