Hi Anthony --
Thanks for the comments.
I have trouble mapping this to a VMM capable of overcommit without just coming back to CMM2.
In CMM2 parlance, ephemeral tmem pools is just normal kernel memory marked in the volatile state, no?
They are similar in concept, but a volatile-marked kernel page
is still a kernel page, can be changed by a kernel (or user)
store instruction, and counts as part of the memory used
by the VM. An ephemeral tmem page cannot be directly written
by a kernel (or user) store,
It seems to me that an architecture built around hinting would be more robust than having to use separate memory pools for this type of memory (especially since you are requiring a copy to/from the pool).
Depends on what you mean by robust, I suppose. Once you
understand the basics of tmem, it is very simple and this
is borne out in the low invasiveness of the Linux patch.
Simplicity is another form of robustness.
The copy may be expensive on an older machine, but on newer
machines copying a page is relatively inexpensive.
On a reasonableBut how would something like specweb do where you should be doing zero-copy IO from the disk to the network? This is the area where I would be concerned. For something like kernbench, you're already bringing the disk data into the CPU cache anyway so I can appreciate that the copy could get lost in the noise.
multi-VM-kernbench-like benchmark I'll be presenting at Linux
Symposium next week, the overhead is on the order of 0.01%
for a fairly significant savings in IOs.