> The problem is that 2MB pages are too much to duplicate for a single byte change. Splitting up such pages into their 4kb counterparts when dirtying a COWed h

> The problem is that 2MB pages are too much to duplicate for a single byte change. Splitting up such pages into their 4kb counterparts when dirtying a COWed huge page isn't particularly crazy. I don't think there's much reason to do that when huge pages are used, but given THP it seems pretty obvious that there's potential for substantial regressions without that feature. > and actually is very hard to do better in user-space with a different persistence model. Howso? It's not like management of a buffering layer over disks is a particularly new thing. There's plenty of different data stores that have persistence models that don't have the problems (uneven write rate, explosion in memory usage after fork, latency increases due to the increase in page misses, ...) of fork() and then writing out the data in the fork.