L1 vs VMM, page file, metadata database

FAQ, getting help, user experience about PrimoCache
Post Reply
OneRoot
Level 1
Level 1
Posts: 1
Joined: Mon Jul 05, 2021 7:54 am

L1 vs VMM, page file, metadata database

Post by OneRoot »

Greetings!

I have recently discovered PrimoCache and have not yet started an evaluation, but after reading the available use cases, guides and this forum, I have three initial questions:

1. L1 cache vs. Windows Virtual Memory Manager.

The VMM normally caches backing file accesses using the Standby memory pool, sizing it automatically depending on memory pressure. It appears that PrimoCache's L1 cache duplicates this built-in functionality.

If I understand correctly, the L1 cache memory pool is useful to increase write IOPs and write bandwidth, in combination with deferred writes.

Is it correct that if I'm not interested in improving write IOP + write bandwidth, I should set the Level-1 cache at minimum, and let the OS cache I/O while taking into account memory pressure?

2. Page file handling

Since PrimoCache operates at block level, does it mean it will cache blocks of the page file, if the page file is placed on a cached partition? If the page file were to become heavily thrashed, its contents would be frequently read, leading to the naive interpretation that it should be cached (in memory, thus further increasing the thrashing, and/or on SSD, thus unnecessarily wearing it out). Is there a special case handler for the pagefile whereby it is never a caching candidate?

I can put the pagefile on a separate, uncached partition, but then I miss out on the auto-sizing feature of windows, since page file partition size would be fixed at creation time.

3. Metadata database maintenance

I assume that PrimoCache keeps a database (on the cache volume) of LRU data which is used in deciding how the cache is allocated. How is the LRU data maintained? Specifically, what mechanisms are in place to prevent a stream of LRU data being continuously updated, causing erase cycle wear and tear on the cache drive?

Is it possible, or are there plans to enable LRU updates only when the cache hit rate drops below some threshold? Ie, freshen the cache only when I/O performance drops, rather than continuously?

Thank you kindly
User avatar
Jaga
Contributor
Contributor
Posts: 692
Joined: Sat Jan 25, 2014 1:11 am

Re: L1 vs VMM, page file, metadata database

Post by Jaga »

Will attempt to give good answers, though based on experience you may find your results vary from my own.


1) If I were able to, I'd disable any Windows volume caching completely and stick with Primocache for 100% caching duty. It's just far far better overall in how it manages volumes and the most-used/least-used data on them. Since it's virtually impossible to do that however, I just leave Windows alone and use however much memory I am comfortable giving Primocache, and let Windows "sort out it's own remaining memory". Typically the less Windows has access to (after a L1 cache is set up), the less it will reserve memory for it's own cache, which forces more into Primocache. Usually that results in a win-win scenario.

If you're concerned at all with memory use (and Primocache overhead), increase the Cache Task's block size a bit to reduce that overhead. The smallest size *usually* is the fastest, but it all really depends on the average size of files that you are reading/writing on the drive. I find that either 8KB or 16KB blocks do the job nicely for standard data - if your files are overall larger, increase block size and re-test. For much larger files, a larger block size is advantageous (sometimes hugely).


2) Primocache runs at the kernel level, meaning it loads at the same time Windows does (before the application layer). Any files on the logical volume you tell it to cache will be cached, including the page file. If that's undesirable, you can re-size the volume you are caching to be a little smaller, then create a new volume just for the pagefile that won't be cached. Static pagefile on a static separate volume, and it won't chew up any L1 space.


3) Support will have to answer this one in more detail. I haven't noticed a significant amount of wear and tear on the primary (boot) volume due to Primocache's activities. Most of the block tracking happens in the "overhead" it sets up in memory, and probably never hits the boot volume except at shutdown if you use "prefetch last cache" (possibly also at regular intervals as updates).
User avatar
Support
Support Team
Support Team
Posts: 3623
Joined: Sun Dec 21, 2008 2:42 am

Re: L1 vs VMM, page file, metadata database

Post by Support »

OneRoot wrote: Mon Jul 05, 2021 8:42 am How is the LRU data maintained? Specifically, what mechanisms are in place to prevent a stream of LRU data being continuously updated, causing erase cycle wear and tear on the cache drive?
They are stored in additional memory allocated, as known as "overhead".
Post Reply