Matthew, First of all, thank you for doing this job! Supporting persistent memory for any OS is bit more than adding "just another device". There are some thoughts and questions below. Perhaps, you discussed those already. If so, please point me to that discussion! > > Few questions: > > - why would you need Dirty for DAX? > > One of the areas ignored by the original XIP code was CPU caches. Maybe > s390 has write-through caches or something, but on x86 we need to write back the > lines from the CPU cache to the memory on an msync(). We'll also need to do this for > a write(), although that's a SMOP. > X86 cache lines are much smaller than a page. Cache lined are flushed "naturally", but we do not know about that. How many Dirty pages do we anticipate? What is the performance cost of msync()? Is that higher, if we do page-based accounting? Reasons and frequency of msync(): Atomicity: needs barriers, happens frequently, leaves relatively small number of Dirty pages. Here the cost is probably smaller. Durability of application updates: issued infrequently, leaves many Dirty pages. The cost could be high, right? Let's assume that at some point we get CPU/Persistent Memory Controller combinations that support atomicity of multiple updates in hardware. Would you need to mark pages Dirty in such cases? If not, what is the right layer build that support for x86? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
