Troy Benjegerdes <hozer@xxxxxxxxx> wrote: > I would like to suggest that cache culling be driven by a userspace > daeomon, with LRU usage being used as a fallback approach if the > userspace app doesn't respond fast enough. Or at the least provide a way > to load modules to provide different culling algorithms. I suppose that shouldn't be too hard; the problem that I can see is deciding how much space to reserve in an inode slot for culling decision data. For instance, with the LRU approach, I just keep a 32-bit atime per inode which I update any time I match that inode. However, I can see ways in which the culling heuristic might be weighted: (*) Favour culling of large files over small ones or small over large. (*) Mark files for preferential retention, perhaps by source. > If the server is responding and delivering files faster than we can > write them to local disk and cull space, should we really be caching at > all? Is it even appropriate for the kernel to make that decision? That's a very tricky question, and it's most likely when the network + server retrieval speeds are better than the disk retrieval speeds, in which case you shouldn't be using a cache, except for the cases of where you want to be able to live without the server for some reason or other; and there the cache is being used to enhance reliability, not speed. However, we do need to control turnover on the cache. If the rate is greater than we can sustain, there needs to be a way to suspend caching on certain files, but what the heuristic for that should be, I'm not sure. CacheFS on one very large file nets me something like a 700% performance increase[*] on an old dual-PPro machine with a warm cache on a 7200rpm HDD vs a 100Mbps network link to the server. The file is larger than the machine's memory. I believe Steve Dickson doesn't really see any advantage of using the cache with a 1Gbps network link to his server. David
