lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1502031213520.18250@chino.kir.corp.google.com>
Date:	Tue, 3 Feb 2015 12:16:32 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Minchan Kim <minchan@...nel.org>
cc:	Petr Cermak <petrcermak@...omium.org>,
	Primiano Tucci <primiano@...omium.org>,
	"Kirill A. Shutemov" <kirill@...temov.name>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Hugh Dickins <hughd@...gle.com>
Subject: Re: [PATCH v2 2/2] task_mmu: Add user-space support for resetting
 mm->hiwater_rss (peak RSS)

On Wed, 4 Feb 2015, Minchan Kim wrote:

> > > 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.
> > 
> > I understand your concern, but I hope you agree that the functionality we
> > are proposing would be very useful for profiling. Therefore, I suggest
> > adding an extra resettable field to /proc/pid/status (e.g.
> > resettable_hiwater_rss) instead. What is your view on this approach?
> 
> The idea would be very useful for measuring working set size for
> efficient memory management in userside, which becomes very popular
> with many platforms for embedded world with tight memory.
> 

The problem is the same as the aforementioned if you're only going to be 
adding one field.  If another process happens to clear the 
resettable_hiwater_rss before you can read it, you don't see potentially 
large spikes in size.

I understand the need for measuring working set size, and we have an 
in-house solution for that, but I don't think we should be introducing new 
fields that require only one root process on the system to be touching it 
for it to be effective.  Let me talk with some people about how difficult 
it would be to propose our in-house solution.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ