On 8/17/21 10:54 PM, Vivek Goyal wrote: [...] >> >> As for virtiofs, Dr. David Alan Gilbert has mentioned that various files >> may compete for limited DAX window resource. >> >> Besides, supporting DAX for small files can be expensive. Small files >> can consume DAX window resource rapidly, and if small files are accessed >> only once, the cost of mmap/munmap on host can not be ignored. > > W.r.r access pattern, same applies to large files also. So if a section > of large file is accessed only once, it will consume dax window as well > and will have to be reclaimed. > > Dax in virtiofs provides speed gain only if map file once and access > it multiple times. If that pattern does not hold true, then dax does > not seem to provide speed gains and in fact might be slower than > non-dax. > > So if there is a pattern where we know some files are accessed repeatedly > while others are not, then enabling/disabling dax selectively will make > sense. Question is how many workloads really know that and how will > you make that decision. Do you have any data to back that up. Empirically, some files are naturally accessed only once, such as configuration files under /etc/ directory, .py, .js files, etc. It's the real case that we have met in real world. While some others are most likely accessed multiple times, such as .so libraries. With per-file DAX feature, administrator can decide on their own which files shall be dax enabled and thus gain most benefit from dax, while others not. As for how we can distinguish the file access mode, besides the intuitive insights described previously, we can develop more advanced method distinguishing it, e.g., scanning the DAX window map and finding the hot files. With the mechanism offered by kernel, more advanced strategy can be developed then. > > W.r.t small file, is that a real concern. If that file is being accessed > mutliple times, then we will still see the speed gain. Only down side > is that there is little wastage of resources because our minimum dax > mapping granularity is 2MB. I am wondering can we handle that by > supporting other dax mapping granularities as well. say 256K and let > users choose it. > -- Thanks, Jeffle
