On 04/09/2013 03:10 AM, KOSAKI Motohiro wrote: >> This approach works on any task via it's proc, and can be used on different >> tasks in parallel. >> >> Also, Andrew was asking for some performance numbers related to the change. >> Now I can say, that as long as soft dirty bits are not cleared, no >> performance >> penalty occur, since the soft dirty bit and the regular dirty bit are set at >> the same time within the same instruction. When soft dirty is cleared via >> clear_refs, the task in question might slow down, but it will depend on how >> actively it uses the memory. >> >> >> What do you think, does it make sense to develop this approach further? > > When touching mmaped page, cpu turns on dirty bit but doesn't turn on soft > dirty.
Yes. BTW, I've just thought that "soft" in soft dirty should be read as softWARE, i.e. this bit is managed by kernel, rather than CPU. > So, I'm not convinced how to use this flag. Please show us your userland > algorithm > how to detect diff. It's like this: 1. First do "echo 4 > /proc/$pid/clear_refs". At that point kernel clears the soft dirty _and_ the writable bits from all ptes of process $pid. From now on every write to any page will result in #pf and the subsequent call to pte_mkdirty/pmd_mkdirty, which in turn will set the soft dirty flag. 2. Then read the /proc/$pid/pagemap (well, /proc/$pid/pagemap2 when it will appear) and check the soft-dirty bit reported there (in this RFC patch it's the PM_SOFT_DIRTY one). If set, the respective pte was written to since last call to clear refs. Thanks, Pavel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
