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
Hello,
On Tue, Feb 03, 2015 at 03:26:28AM +, Petr Cermak wrote:
> On Mon, Jan 26, 2015 at 04:00:20PM -0800, David Rientjes 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
> >
Hello,
On Tue, Feb 03, 2015 at 03:26:28AM +, Petr Cermak wrote:
On Mon, Jan 26, 2015 at 04:00:20PM -0800, David Rientjes 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
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
On Mon, Jan 26, 2015 at 04:00:20PM -0800, David Rientjes 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
>
On Mon, Jan 26, 2015 at 04:00:20PM -0800, David Rientjes 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
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
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
On Thu, Jan 22, 2015 at 11:27 PM, David Rientjes 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? How can
you see a hwm
On Thu, 22 Jan 2015, Primiano Tucci wrote:
> > I think the bigger concern would be that this, and any new line such as
> > resettable_hiwater_rss, invalidates itself entirely. Any process that
> > checks the hwm will not know of other processes that reset it, so the
> > value itself has no
On Thu, 22 Jan 2015, Primiano Tucci wrote:
I think the bigger concern would be that this, and any new line such as
resettable_hiwater_rss, invalidates itself entirely. Any process that
checks the hwm will not know of other processes that reset it, so the
value itself has no significance
On Thu, Jan 22, 2015 at 11:27 PM, David Rientjes rient...@google.com 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? How
On Wed, Jan 21, 2015 at 10:58 PM, David Rientjes wrote:
> I think the bigger concern would be that this, and any new line such as
> resettable_hiwater_rss, invalidates itself entirely. Any process that
> checks the hwm will not know of other processes that reset it, so the
> value itself has no
On Thu, 15 Jan 2015, Kirill A. Shutemov wrote:
> I'm not sure if it should be considered ABI break or not. Just asking.
>
> I would like to hear opinion from other people.
>
I think the bigger concern would be that this, and any new line such as
resettable_hiwater_rss, invalidates itself
On Wed, Jan 21, 2015 at 10:58 PM, David Rientjes rient...@google.com wrote:
I think the bigger concern would be that this, and any new line such as
resettable_hiwater_rss, invalidates itself entirely. Any process that
checks the hwm will not know of other processes that reset it, so the
value
On Thu, 15 Jan 2015, Kirill A. Shutemov wrote:
I'm not sure if it should be considered ABI break or not. Just asking.
I would like to hear opinion from other people.
I think the bigger concern would be that this, and any new line such as
resettable_hiwater_rss, invalidates itself
On Thu, Jan 15, 2015 at 01:36:30AM +0200, Kirill A. Shutemov wrote:
> On Wed, Jan 14, 2015 at 03:22:25PM +, Petr Cermak wrote:
> > On Wed, Jan 07, 2015 at 07:24:52PM +0200, Kirill A. Shutemov wrote:
> > > And how it's not an ABI break?
> > I don't think this is an ABI break because the current
On Thu, Jan 15, 2015 at 01:36:30AM +0200, Kirill A. Shutemov wrote:
On Wed, Jan 14, 2015 at 03:22:25PM +, Petr Cermak wrote:
On Wed, Jan 07, 2015 at 07:24:52PM +0200, Kirill A. Shutemov wrote:
And how it's not an ABI break?
I don't think this is an ABI break because the current
On Wed, Jan 14, 2015 at 03:22:25PM +, Petr Cermak wrote:
> On Wed, Jan 07, 2015 at 07:24:52PM +0200, Kirill A. Shutemov wrote:
> > And how it's not an ABI break?
> I don't think this is an ABI break because the current behaviour is not
> changed unless you write "5" to /proc/pid/clear_refs. If
On Wed, Jan 14, 2015 at 03:22:25PM +, Petr Cermak wrote:
> On Wed, Jan 07, 2015 at 07:24:52PM +0200, Kirill A. Shutemov wrote:
> > And how it's not an ABI break?
> I don't think this is an ABI break because the current behaviour is not
> changed unless you write "5" to /proc/pid/clear_refs. If
On Wed, Jan 07, 2015 at 07:24:52PM +0200, Kirill A. Shutemov wrote:
> And how it's not an ABI break?
I don't think this is an ABI break because the current behaviour is not
changed unless you write "5" to /proc/pid/clear_refs. If you do, you are
explicitly requesting the new functionality.
> We
On Wed, Jan 14, 2015 at 03:22:25PM +, Petr Cermak wrote:
On Wed, Jan 07, 2015 at 07:24:52PM +0200, Kirill A. Shutemov wrote:
And how it's not an ABI break?
I don't think this is an ABI break because the current behaviour is not
changed unless you write 5 to /proc/pid/clear_refs. If you
On Wed, Jan 14, 2015 at 03:22:25PM +, Petr Cermak wrote:
On Wed, Jan 07, 2015 at 07:24:52PM +0200, Kirill A. Shutemov wrote:
And how it's not an ABI break?
I don't think this is an ABI break because the current behaviour is not
changed unless you write 5 to /proc/pid/clear_refs. If you
On Wed, Jan 07, 2015 at 07:24:52PM +0200, Kirill A. Shutemov wrote:
And how it's not an ABI break?
I don't think this is an ABI break because the current behaviour is not
changed unless you write 5 to /proc/pid/clear_refs. If you do, you are
explicitly requesting the new functionality.
We have
On Wed, Jan 07, 2015 at 05:06:54PM +, Petr Cermak wrote:
> Peak resident size of a process can be reset by writing "5" to
> /proc/pid/clear_refs. The driving use-case for this would be getting the
> peak RSS value, which can be retrieved from the VmHWM field in
> /proc/pid/status, per
Peak resident size of a process can be reset by writing "5" to
/proc/pid/clear_refs. The driving use-case for this would be getting the
peak RSS value, which can be retrieved from the VmHWM field in
/proc/pid/status, per benchmark iteration or test scenario.
Signed-off-by: Petr Cermak
---
Peak resident size of a process can be reset by writing 5 to
/proc/pid/clear_refs. The driving use-case for this would be getting the
peak RSS value, which can be retrieved from the VmHWM field in
/proc/pid/status, per benchmark iteration or test scenario.
Signed-off-by: Petr Cermak
On Wed, Jan 07, 2015 at 05:06:54PM +, Petr Cermak wrote:
Peak resident size of a process can be reset by writing 5 to
/proc/pid/clear_refs. The driving use-case for this would be getting the
peak RSS value, which can be retrieved from the VmHWM field in
/proc/pid/status, per benchmark
28 matches
Mail list logo
