Re: [PATCH v2 2/2] task_mmu: Add user-space support for resetting mm->hiwater_rss (peak RSS)

[David Rientjes]

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/