Suggestions around PrimoCache
3 posts • Page 1 of 1
Hello, I have a suggestion, for usb L2 cache. Earlier Microsoft introduced two technologies inside Windows Vista, which was later mastered in 7, these two technologies being superfetch and readyboost. Both of them were great ideas, however readyboost had one specific flaw, that you guys had technically fixed, but at the loss of a "double-edged sword." Now readyboost is actually similar to your software, as it uses an "interception" type of design, in which it caches all 4k reads from a hard drive, the moment the service starts, whether they be from, a program, page file, etc. This design works very well in tandem with a hard drive, because hard drives are good at sequential reads, but are slow at random reads. It is a basic flaw with the technology, while flash memory was the exact opposite, poor at sequential, but good at random. However the main issue with readyboost was that Microsoft designed it for security, rather than raw performance, which is where you guys could come in. Although readyboost was a good design it just couldn't remember the cache after a boot (and I believe hibernation if not on a pcie bus.) This flaw made it almost redundant if the user had plenty of ram, as ram was slowly filled along with the readyboost device. Your version fixes that, as it remembers L2 cache but also seems to have the opposite design flaw from Microsoft! Microsoft designed readyboost where it could see the difference in random reads vs sequential. Whenever a random read would occur readyboost would boost performance, but on a sequential read it would get out of the way and let the hard drive service that request. Your usb L2 cache doesn't seem to have that ability, and any usb device would attempt to overpower the drive in sequential reads, leading to a performance loss. If possible you should make Primocache detect if L2 cache can beat the drive it's caching with sequential reads (ssd,) via an internal benchmark. If it cannot (usb) and detects the drive as slower in sequential performance it should get out of the way and let the drive perform the sequential reads, while it simply handles any small randoms. That would basically be L2 cache done right, as far as reads are concerned.
I would also suggest that the cache leave some buffer for lazy-writing to the USB device, as they typically have much lower write speeds than read, especially with random writes. Grouping small 4k writes into larger (>512k) writes to the USB would be even more helpful.