Precache locks content when locking of precache not selected Topic is solved

Found a bug? Report here
Post Reply
RobF99
Level 8
Level 8
Posts: 130
Joined: Fri Sep 19, 2014 5:14 am

Precache locks content when locking of precache not selected

Post by RobF99 »

Windows OS:10
Hardware Information DELL XPS
    CPU: I7
    Main Board: INTEL
    Memory:32 Gb
    Hard Drives: 1 Tb, 3 Tb, 4 Tb
PrimoCache Version: 4.1.0
Screenshot(s) of your PrimoCache's main dialog showing cache configuration and statistics:

Problem Description:
It appears that Prefetch Last Cache locks the cache content whether you have that box checked or not.

I have C,D,E and G all cached on a 450 L2 100% Read and 25 L1 (23.75R1.25W).

With a full L1 after a reboot it would precache approx 5 Gb of C, 1 Gb of D, 15 Gb of E and 3 Gb of G.

I then copied a lot of files from C in around 20 Gb chunks to a non cached external drive.

I noticed each time it would read some data from L1 but most from L2. I copied the data 5 times and saw the same pattern each time. I rebooted the system and Prefetch prefetched the same amount. 5 Gb of C, 1 Gb of D, 15 Gb of E and 3 Gb of G. So it was never evicting data from any of the drives from L1 when it was copying this 20 Gb of data.

So it looks like it did lock the precache and it is definitely turned off. I am a very experienced PrimoCache user.
User avatar
Support
Support Team
Support Team
Posts: 3623
Joined: Sun Dec 21, 2008 2:42 am

Re: Precache locks content when locking of precache not selected

Post by Support »

This is because L1 is full and all data have been cached in L1 or L2. No new data comes, so no cache will be evicted. L1 cache is almost not changed, thus prefetch will not changed too. If you read new data (not cached by L1/L2) from C/D/E/G, it shall change.
RobF99
Level 8
Level 8
Posts: 130
Joined: Fri Sep 19, 2014 5:14 am

Re: Precache locks content when locking of precache not selected

Post by RobF99 »

Ok. I understand. I thought the L2 read would move to L1 and evict anything old in L1. Thanks.
RobF99
Level 8
Level 8
Posts: 130
Joined: Fri Sep 19, 2014 5:14 am

Re: Precache locks content when locking of precache not selected

Post by RobF99 »

Support, please note that I am quite sure that there is a problem here, but it is not related to prefetch. This issue seems to occur when L1 cache is full, and you have an Individual read/write size. e.g. 80% read and 20% write. I had 3 folders of around 4.4 Gb each. I was copying the folder to a non cached drive one folder at a time. Each time, it would read from L2 and would never evict any L1 cache and promote the data to L1 cache. I repeated it 10 times, and it kept reading from L2 cache.

I then turned off Individual Read/Write so L1 was read/write. After the first copying of the folders they read from L2, but the next time they did read from L1. So this time L1 data was evicted and replaced with these files. So it seems when there is individual read/write cache that it doesn't evict the L1 cache. I had these same settings of individual read/write when I originally posted this message thinking that it was PreCache locking the cache. Instead it seems when L1 cache is full and individual read/write is set data read from L2 does not go into L1.
User avatar
Support
Support Team
Support Team
Posts: 3623
Joined: Sun Dec 21, 2008 2:42 am

Re: Precache locks content when locking of precache not selected

Post by Support »

Promoting from L2 to L1 only happens when L1 cache has free space. When you turned off Individual Read/Write on L1, L1 cache got reset and had free space, so you saw the promoting.
RobF99
Level 8
Level 8
Posts: 130
Joined: Fri Sep 19, 2014 5:14 am

Re: Precache locks content when locking of precache not selected

Post by RobF99 »

Ok. That explains it then. Of course, this now becomes a feature request - :) as an option, perhaps.

I noticed that it also happens when R/W is shared. So I think this always happens if L1 is full regardless of R/W individual settings.

As I understand (and you can correct me if I am wrong), it will leave data in L1 cache data that most likely is now more LRU and should be evicted. Since the data that was in L2 cache now becomes hotter, it is penalized by lower performance if it is needed again soon. The only way that L1 will free up generally is if you have Free cache on written turned on. If that is not on, then the only data that will get into L1 is new data (and no L2 data). I don't think it is expensive to exchange data between L1 and L2? If there is less hot data in L1, evict data from L1 and put it into L2 gather queue and replace with L2 just read. That evicted L1 data is probably already in L2 anyway and may not need to be gathered and just its LRU ranking changed.

Edit: Also, I understand that the O/S would cache the data anyway, so it might not matter. I noticed it because I was doing unbuffered reads, and so it wasn't cached by Windows anyway.
User avatar
Support
Support Team
Support Team
Posts: 3623
Joined: Sun Dec 21, 2008 2:42 am

Re: Precache locks content when locking of precache not selected

Post by Support »

RobF99 wrote: Mon Dec 20, 2021 10:23 am I don't think it is expensive to exchange data between L1 and L2?
PrimoCache uses "async" method to exchange data between L1 and L2. Data evicted from L1 is not immediately written to L2 (assuming data haven't been cached by L2). During this period, these data are not available in L1 or L2. So to give better cache coverage, we don't promote data from L2 to L1 when L1 is full. Besides, as you said, Windows also has its internal cache, so this promotion doesn't generate great benefit.
RobF99
Level 8
Level 8
Posts: 130
Joined: Fri Sep 19, 2014 5:14 am

Re: Precache locks content when locking of precache not selected

Post by RobF99 »

Sorry, I wish to contradict your argument here because in the past couple of days I experienced a situation that is not desirable from an L1 best speed point of view.

If a user has 8 Gb L1 and writes an 8Gb file and fills the L1 cache with write data and then continues using his PC normally for the next 8 hours and say all (or most) of the data he accesses is already in L2, then for all that time he will only get L2 read performance (if Windows hasn't cached the data). The only thing that will replace that L1 data is new write data and a little bit of new read data (because most reads are already from L2), so that L1 8Gb write data that probably will not be accessed again will remain as the main data in L1, even if it won't be accessed again at all. This is not rare because a lot of users are often copying large files.

I think it should always comply with the cascade of Windows Cache => L1 =>L2 so that most recently read data should always be put into L1 because afterall it was the most recently read data and should get highest privilege to L1. A user's hottest data may not make it back to L1 for a long time if it was evicted by a big write.

I know it adds complexity but it could be done as a housekeeping task when system is idle.

I know you told me previously that Free Cache on Written is more of a legacy feature but believe it or not, it does solve this problem. So I use that feature now to avoid this problem. It is great to know that there is flexibility already built in to avoid this issue. I know that this solves that potential issue but most users might not.
User avatar
Support
Support Team
Support Team
Posts: 3623
Joined: Sun Dec 21, 2008 2:42 am

Re: Precache locks content when locking of precache not selected

Post by Support »

RobF99 wrote: Sun Jan 02, 2022 11:50 am If a user has 8 Gb L1 and writes an 8Gb file and fills the L1 cache with write data and then continues using his PC normally for the next 8 hours and say all (or most) of the data he accesses is already in L2, then for all that time he will only get L2 read performance (if Windows hasn't cached the data).
Yes, that's true. I agree with your points and will report this issue to the R&D team.
RobF99 wrote: Sun Jan 02, 2022 11:50 am I know you told me previously that Free Cache on Written is more of a legacy feature but believe it or not, it does solve this problem. So I use that feature now to avoid this problem.
This works because write-blocks are queued to the free-block list after written, making that L1 cache is not full and consequently able to promote L2 cache. We even hadn't thought of this effect before. Thanks for pointing this out :thumbup:
Post Reply