On Fri, 23 Jan 2015, Primiano Tucci wrote: > > If you reset the hwm for a process, rss grows to 100MB, another process > > resets the hwm, and you see a hwm of 2MB, that invalidates the hwm > > entirely. > > Not sure I follow this scenario. Where does the 2MB come from? It's a random number that the hwm gets reset to after the other process clears it. > How can > you see a hwm of 2MB, under which conditions? HVM can never be < RSS. > Again, what you are talking about is the case of two profilers racing > for using the same interface (hwm). > This is the same case today of the PG_referenced bit. > PG_referenced bit is not tracking the highest rss a process has ever attained. PG_referenced is understood to be clearable at any time and the only guarantee is that it was at least cleared before returning from the write. It could be set again before the write returns as well, but we can be sure that it was at least cleared. With your approach, which completely invalidates the entire purpose of hwm, the following is possible: process A process B --------- --------- read hwm = 50MB read hwm = 50MB write to clear hwm rss goes to 100MB write to clear hwm rss goes to 2MB read hwm = 2MB read hwm = 2MB This is a result of allowing something external (process B) be able to clear hwm so that you never knew the value went to 100MB. That's the definition of a race, I don't know how to explain it any better and making any connection between clearing PG_referenced and mm->hiwater_rss is a stretch. This approach just makes mm->hiwater_rss meaningless. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>