Added memory pressure monitor for linux.

Added memory pressure monitor for linux.

Note that I don't know much about linux memory usage. The chromeos
version considered the virtual z(ram) in the total memory and the file
memory as easily reclaimable in the available memory. I removed those.

Methodology: added some debug logging and filled /dev/shm/ until chrome
crashed (The percentage returned by GetusedMemoryInPercent was 98% at
that point).

BUG=

[proberge, 2015-07-23 19:08:19]

proberge@chromium.org changed reviewers:
+ chrisha@chromium.org

[chrisha, 2015-07-24 13:25:46]

https://codereview.chromium.org/1250093006/diff/20001/base/memory/memory_pres...
File base/memory/memory_pressure_monitor_linux.cc (left):

https://codereview.chromium.org/1250093006/diff/20001/base/memory/memory_pres...
base/memory/memory_pressure_monitor_linux.cc:258: int file_memory =
info.active_file + info.inactive_file;
Is this not also true on Linux? ChromeOS is linux based, so I imagine it is true
(ie: dirty file memory simply needs to be shunted to disk to make it available).

https://codereview.chromium.org/1250093006/diff/20001/base/memory/memory_pres...
File base/memory/memory_pressure_monitor_linux.cc (right):

https://codereview.chromium.org/1250093006/diff/20001/base/memory/memory_pres...
base/memory/memory_pressure_monitor_linux.cc:37: UMA_MEMORY_PRESSURE_LEVEL_NONE
= 0,
If we're going to change the name here, I'd make it
MEMORY_PRESSURE_LEVEL_UMA_NONE, to be consistent with the enum name itself.

https://codereview.chromium.org/1250093006/diff/20001/base/memory/memory_pres...
base/memory/memory_pressure_monitor_linux.cc:127: // and the internal functions
are.
These comments probably don't apply to the Linux observer?

https://codereview.chromium.org/1250093006/diff/20001/base/memory/memory_pres...
File base/memory/memory_pressure_monitor_linux.h (right):

https://codereview.chromium.org/1250093006/diff/20001/base/memory/memory_pres...
base/memory/memory_pressure_monitor_linux.h:17: namespace nix {
This doesn't feel like the right namespace.

In fact, we probably shouldn't even have this namespace, nor should we have a
MemoryPressureMonitor base class.

We've been wanting to clean this up for a while by removing the base class,
putting all header stuff in a single .h file, with OS differences hidden behind
precompiler conditionals. Then, common implementation bits (there might be some)
in a .cc, and OS specific implementation details in _win.cc, _mac.cc, _linux.cc,
_chromeos.cc. Look at base/process/process_info.* for an example.

https://codereview.chromium.org/1250093006/diff/20001/base/memory/memory_pres...
base/memory/memory_pressure_monitor_linux.h:50: };
This ends up copying a *lot* from the ChromeOS pressure monitor. It would be
simpler if there was one we could reuse from those two platforms, as they are
going to be mostly the same. Any slight differences in logic would be easily
hidden behind precompiler conditionals, no?

[proberge, 2015-07-24 14:37:37]

Addressed the comments on the .cc file, currently working on refactoring as per
comments on the .h file.

https://codereview.chromium.org/1250093006/diff/20001/base/memory/memory_pres...
File base/memory/memory_pressure_monitor_linux.cc (left):

https://codereview.chromium.org/1250093006/diff/20001/base/memory/memory_pres...
base/memory/memory_pressure_monitor_linux.cc:258: int file_memory =
info.active_file + info.inactive_file;
On 2015/07/24 13:25:45, chrisha wrote:
> Is this not also true on Linux? ChromeOS is linux based, so I imagine it is
true
> (ie: dirty file memory simply needs to be shunted to disk to make it
available).

My methodology could be wrong (writing large files to dev/shm) but this is what
I observe:
* Without adding file_memory to available_memory, the last reported percentage
before the oom killer closes one of my chrome windows is 99%.
* When adding file_memory to available_memory, the last reported percentage
before the oom killer closes one of my chrome windows is 65%.

https://codereview.chromium.org/1250093006/diff/20001/base/memory/memory_pres...
File base/memory/memory_pressure_monitor_linux.cc (right):

https://codereview.chromium.org/1250093006/diff/20001/base/memory/memory_pres...
base/memory/memory_pressure_monitor_linux.cc:37: UMA_MEMORY_PRESSURE_LEVEL_NONE
= 0,
On 2015/07/24 13:25:45, chrisha wrote:
> If we're going to change the name here, I'd make it
> MEMORY_PRESSURE_LEVEL_UMA_NONE, to be consistent with the enum name itself.

It's to be consistent with the enum in memory_pressure_monitor_win.cc which also
logs to the Memory.PressureLevel histogram instead of
ChromeOS.MemoryPressureLevel.

https://codereview.chromium.org/1250093006/diff/20001/base/memory/memory_pres...
base/memory/memory_pressure_monitor_linux.cc:127: // and the internal functions
are.
On 2015/07/24 13:25:45, chrisha wrote:
> These comments probably don't apply to the Linux observer?

Done.

[proberge, 2015-07-24 19:03:10]

https://codereview.chromium.org/1250093006/diff/20001/base/memory/memory_pres...
File base/memory/memory_pressure_monitor_linux.h (right):

https://codereview.chromium.org/1250093006/diff/20001/base/memory/memory_pres...
base/memory/memory_pressure_monitor_linux.h:17: namespace nix {
On 2015/07/24 13:25:46, chrisha wrote:
> This doesn't feel like the right namespace.
> 
> In fact, we probably shouldn't even have this namespace, nor should we have a
> MemoryPressureMonitor base class.
> 
> We've been wanting to clean this up for a while by removing the base class,
> putting all header stuff in a single .h file, with OS differences hidden
behind
> precompiler conditionals. Then, common implementation bits (there might be
some)
> in a .cc, and OS specific implementation details in _win.cc, _mac.cc,
_linux.cc,
> _chromeos.cc. Look at base/process/process_info.* for an example.

Done, but note that my C++ is very rusty and that I most likely made several
design mistakes during the refactor. Please don't hold back on your comments.

https://codereview.chromium.org/1250093006/diff/20001/base/memory/memory_pres...
base/memory/memory_pressure_monitor_linux.h:50: };
On 2015/07/24 13:25:46, chrisha wrote:
> This ends up copying a *lot* from the ChromeOS pressure monitor. It would be
> simpler if there was one we could reuse from those two platforms, as they are
> going to be mostly the same. Any slight differences in logic would be easily
> hidden behind precompiler conditionals, no?

Removed some more logic. If we were to merge the two into one file (with
precompiler conditionals), wouldn't it be confusing for it to be in
memory_pressure_listener.cc ?

[mario.endlessm, 2016-01-28 16:07:45]

Hi. It looks like this work never landed, in which case I'd be curious to know
why that would be the case, since I'm quite interested in this feature (already
doing some experiments in a local branch).

To my inexpert eye, it looks like this patch set prepares the ground work for
having a memory pressure monitor on linux quite nicely, which seems consistent
with what is mentioned in a post[1] I came across recently, about the "tab
discarding" feature:

"""
We’ve enabled the tab discarding experiment in Chrome Canary for Windows and Mac
OS, with a Linux implementation coming soon.
"""

Perhaps this is being developed somewhere else now?

[1] https://developers.google.com/web/updates/2015/09/tab-discarding?hl=en

[proberge, 2016-01-28 17:45:12]

On 2016/01/28 16:07:45, mario.endlessm wrote:
> Hi. It looks like this work never landed, in which case I'd be curious to know
> why that would be the case, since I'm quite interested in this feature
(already
> doing some experiments in a local branch).
> 
> To my inexpert eye, it looks like this patch set prepares the ground work for
> having a memory pressure monitor on linux quite nicely, which seems consistent
> with what is mentioned in a post[1] I came across recently, about the "tab
> discarding" feature:
> 
> """
> We’ve enabled the tab discarding experiment in Chrome Canary for Windows and
Mac
> OS, with a Linux implementation coming soon.
> """
> 
> Perhaps this is being developed somewhere else now?
> 
> [1] https://developers.google.com/web/updates/2015/09/tab-discarding?hl=en

Hi Mario,

This ended up landing as
src/components/memory_pressure/direct_memory_pressure_calculator_linux.h

Sorry for the confusion

[mario.endlessm, 2016-02-03 15:23:30]

On 2016/01/28 17:45:12, proberge wrote:
> [...]
> Hi Mario,
> 
> This ended up landing as
> src/components/memory_pressure/direct_memory_pressure_calculator_linux.h
> 
> Sorry for the confusion

No problem, that's very useful information anyway. Thanks a lot for the pointer.

[mario.endlessm, 2016-02-03 19:07:15]

On 2016/02/03 15:23:30, mario.endlessm wrote:
> On 2016/01/28 17:45:12, proberge wrote:
> > [...]
> > Hi Mario,
> > 
> > This ended up landing as
> > src/components/memory_pressure/direct_memory_pressure_calculator_linux.h
> > 
> > Sorry for the confusion
> 
> No problem, that's very useful information anyway. Thanks a lot for the
pointer.

Btw, sorry for the dumb question but I've been trying to test this
DirectMemoryPressureCalculator thing and I'm clearly missing something, because
I can't see in the code where and/or how this is exactly used. Would you mind
sharing some hints? 

I do have a fresh checkout of chromium from master, fwiw.

Thanks in advance!

[proberge, 2016-02-03 19:21:02]

On 2016/02/03 19:07:15, mario.endlessm wrote:
> On 2016/02/03 15:23:30, mario.endlessm wrote:
> > On 2016/01/28 17:45:12, proberge wrote:
> > > [...]
> > > Hi Mario,
> > > 
> > > This ended up landing as
> > > src/components/memory_pressure/direct_memory_pressure_calculator_linux.h
> > > 
> > > Sorry for the confusion
> > 
> > No problem, that's very useful information anyway. Thanks a lot for the
> pointer.
> 
> Btw, sorry for the dumb question but I've been trying to test this
> DirectMemoryPressureCalculator thing and I'm clearly missing something,
because
> I can't see in the code where and/or how this is exactly used. Would you mind
> sharing some hints? 
> 
> I do have a fresh checkout of chromium from master, fwiw.
> 
> Thanks in advance!

It seems like they're still in the process of refactoring the memory pressure
code, as there's no outside reference to components/memory_pressure.
You could send an e-mail to the OWNERS of that folder to check up on progress
and/or offer to help:
https://code.google.com/p/chromium/codesearch#chromium/src/components/memory_...

[mario.endlessm, 2016-02-03 19:24:19]

On 2016/02/03 19:21:02, proberge wrote:
> [...]
> It seems like they're still in the process of refactoring the memory pressure
> code, as there's no outside reference to components/memory_pressure.

Thanks for confirming that I'm not mad after all :)

> You could send an e-mail to the OWNERS of that folder to check up on progress
> and/or offer to help:
>
https://code.google.com/p/chromium/codesearch#chromium/src/components/memory_...

Good point. I'll do that after dinner, thanks!