So I have been using 3.0.2 for since it had been released and noticed that L2 write cache get flushed out when using L1 for defer write. When L1 write is not used, the L2 write cache retained and read requested can be fetch from the pool.. Just from testing and seeing the cache get released after write, I think it is a waste of i/o resource having to re-cache the same data by reading it.
Anyway, please implement a fix so L2 write cache don't get evicted when cache data is push to the hard drive and when using with L1 defer write.
By design, L1/L2 write cache will not be released after the cache data is flushed to the underlying disk as long as the option "Free Cache on Written" is not checked.
But during the change of configuration, PrimoCache may release whole cache to apply the new cache configuration.
Can you upload a screenshot showing the cache settings related to this issue?
Here a sample of installing 3Dmark with shared L1/L2 with all status reset. It seem with L1/L2 enable, L1 get the write cache first, then over flow to L2, but only half of the it went to L2. The other half was written directly to the had drive as urgent write. The install time took only 30 seconds with my defer write set to 60 seconds. I make sure my computer were completely idle and no start up programs were run (the best that I can anyway).
1) Before installing 3DMark
before 3dmark.png (66.95 KiB) Viewed 3597 times
2) After installing 3dMark
after 3dmark.png (56.41 KiB) Viewed 3597 times
Last edited by minhgi on Tue Mar 27, 2018 4:00 am, edited 5 times in total.
Here install 3DMark with only L2 and all statistic reset. Without L1, all of the data is written to L2 cache. I wasn't able to produce L2 retention scenario with 3dmark, but is noticeable with a 3-4 hybrid sleep or fast startup. Anyway, I will love to see all of the L1 write cache and urgent write be written to L2 first and then get push down to the hard drive at a set time. I am not sure if that can be can change with a different write cache scheme
1) Before
before 3dmark without l1.png (59.34 KiB) Viewed 3601 times
2) After
after 3dmark without l1.png (55.17 KiB) Viewed 3601 times
minhgi wrote:I wasn't able to produce L2 retention scenario with 3dmark, but is noticeable with a 3-4 hybrid sleep or fast startup
As you said, I don't see the L2 cache retention in these pictures. Perhaps the issue just related to hybrid-sleep or fast-startup?
minhgi wrote: I will love to see all of the L1 write cache and urgent write be written to L2 first and then get push down to the hard drive at a set time.
Current write scheme is designed to maximize writing throughput, that is two storage devices doing write work independently. Not sure if another option will be provided in future.
Actually having all the defer cache written to L2 would allow immediate recall of the same data; there forth, efficiently utilizing the full bandwidth of the SSD. When we have overflow with urgent write involve, only half of the data is in cache and other in hard drive. If the next read data comes from the hard drive, you have an i/o hit that coming from a slower storage device. At the same time, data split written to hard drive and L2 actually slower when installing 10 GB 3dmark software. SSD thoughoutput is allot greater than HHD.
From both tests I can visually see that I can launch 3dmark and start immediately using it with L1 disable. Where when L1 was enable, I have to wait at least 5 seconds for the read to fetch the remaining data from the HHD before 3dmark was usable.
Since SSD and optane are quite efficiently handling loads, all written data should first go to L2 using it as a buffer zone for the slower device. It should be L1-->flush set-time/overflow/urgent write-->L2-->flush set-time-->slower device (hard drive).
Yes, you're right. Current scheme is best for heavy write incoming workload (no need to read back), not best for the scenarios that have data read back. We'll consider adding an option. Thanks.
