Messages in this thread | | | Subject | Re: [PATCH v3 01/17] mm: support madvise(MADV_FREE) | From | Daniel Micay <> | Date | Fri, 13 Nov 2015 01:16:54 -0500 |
| |
On 13/11/15 01:15 AM, Minchan Kim wrote: > On Thu, Nov 12, 2015 at 12:21:30AM -0500, Daniel Micay wrote: >>> I also think that the kernel should commit to either zeroing the page >>> or leaving it unchanged in response to MADV_FREE (even if the decision >>> of which to do is made later on). I think that your patch series does >>> this, but only after a few of the patches are applied (the swap entry >>> freeing), and I think that it should be a real guaranteed part of the >>> semantics and maybe have a test case. >> >> This would be a good thing to test because it would be required to add >> MADV_FREE_UNDO down the road. It would mean the same semantics as the >> MEM_RESET and MEM_RESET_UNDO features on Windows, and there's probably >> value in that for the sake of migrating existing software too. > > So, do you mean that we could implement MADV_FREE_UNDO with "read" > opearation("just access bit marking) easily in future? > > If so, it would be good reason to change MADV_FREE from dirty bit to > access bit. Okay, I will look at that.
I just meant testing that the data is either zero or the old data if it's read before it's written to. Not having it stay around once there is a read. Not sure if that's what Andy meant.
[unhandled content-type:application/pgp-signature] | |