On Wed, Jun 22, 2011 at 11:39:40AM -0400, Rik van Riel wrote: > On 06/22/2011 07:19 AM, Izik Eidus wrote: > > > So what we say here is: it is better to have little junk in the unstable > > tree that get flushed eventualy anyway, instead of make the guest > > slower.... > > this race is something that does not reflect accurate of ksm anyway due > > to the full memcmp that we will eventualy perform... > > With 2MB pages, I am not convinced they will get "flushed eventually", > because there is a good chance at least one of the 4kB pages inside > a 2MB page is in active use at all times. > > I worry that the proposed changes may end up effectively preventing > KSM from scanning inside 2MB pages, when even one 4kB page inside > is in active use. This could mean increased swapping on systems > that run low on memory, which can be a much larger performance penalty > than ksmd CPU use. > > We need to scan inside 2MB pages when memory runs low, regardless > of the accessed or dirty bits. I guess we could fallback to the cksum when a THP is encountered (repeating the test_and_clear_dirty also wouldn't give the expected result if it's repeated on the same hugepmd for the next 4k virtual address candidate for unstable tree insertion, so it'd need special handling during the virtual walk anyway). So it's getting a little hairy, skip on THP, skip on EPT, then I wonder what is the common case that would be left using it... Or we could evaluate with statistic how many less pages are inserted into the unstable tree using the 2m dirty bit but clearly it'd be less reliable, the algorithm really is meant to track the volatility of what is later merged, not of a bigger chunk with unrelated data in it. On a side note, khugepaged should also be changed to preserve the dirty bit if at least one dirty bit of the ptes is dirty (currently the hugepmd is always created dirty, it can never happen for an hugepmd to be clean today so it wasn't preserved in khugepaged so far). -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
