4 ms·
"Modifying a defuplicated page will take longer, because a new copy has to be created." Well, kinda. They only eventually have to be created. You don't have t
by DannyBee 10y ago
"Modifying a defuplicated page will take longer, because a new copy has to be created."
Well, kinda. They only eventually have to be created.
You don't have to create the new copy immediately, you could overlay new data on the old page
(IE create new sparse page. Anything filled in on the new page is read from new page, anything else goes to backing dedupe'd page. real copy is made in background so this goes back to being fast)
Of course, this mostly just makes it harder, assuming you can place enough memory pressure on the machine.
- Filligree 10y agoAnd how would you implement a "sparse page"? Without hardware support, the only idea I can think of is to mark the page unreadable and pass all memory reads through the kernel. Which would be readily detectable... among other problems.
- DannyBee 10y agoSure, you'd need hardware support. But, for example, hardware dedup is infeasible (IE you can make the compression go in hardware, but the management, not so much or sanely. Unless you can make both constant time, ...). Sparse pages are at least feasible in hardware. Also, you realize that passing all memory reads through the kernel is what any read barrier garbage collected language does, right?