Trying again to land OOM priority manager changes.

Trying again to land OOM priority manager changes.

First landing failed because of an obscure problem with building
linux_shared. This change passes the linux_shared trybot (and
linux and linux_chromeos trybots).

Changing OOM range to 0, 1000 and tweaking OOM algorithm.

With this change, we now use the newer oom_score_adj file (with
fallback to oom_adj when on a system that doesn't support it) so that
we can take advantage of a finer range ([0, 1000] instead of [0, 15]).

Also tweaked the OOM priority manager to prioritize things in a
slightly different order, preferring (even more) not to kill tabs that
the user has currently selected.

Original review: http://codereview.chromium.org/7671033/

BUG=chromium-os:18421, chromium:65009
TEST=Ran on device, observed OOM adj values, forced OOM conditions to
watch kills.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=97888

[Greg Spencer (Chromium), 2011-08-22 23:28:47]

Sending to steven and brettw because they were the original reviewers.  Only the
part highlighted below has changed.

http://codereview.chromium.org/7708020/diff/2001/base/process_util.h
File base/process_util.h (left):

http://codereview.chromium.org/7708020/diff/2001/base/process_util.h#oldcode176
base/process_util.h:176: static const char kAdjustOOMScoreSwitch[] =
"--adjust-oom-score";
First landing failed because of an obscure problem with building
linux_shared.  This new change is identical to the original, with the
exception that I reverted this minor change that moved a static const
char[] out of process_util.h in base/ (where it should not be, IMO)
and into the .cc file.  Unfortunately, that causes the linux_shared
build to fail for a reason that is still not clear to me, as libbase
is linked into all the executables which failed to link because they
thought this symbol was missing.  They only failed to link in the
linux_shared build, so it certainly has something to do with our
shared library build.

Instead of leaving the static string in process_util.h, I moved it to
be closer to the one call site that used it, since I don't think that
a switch that is used only by the suid sandbox and its callers on
Linux belongs in base/, especially when there is only one use of the
string, and especially not as a static that gets defined in every
compilation unit that includes it. The suid sandbox doesn't include
anything from base, so we can't re-use the string there.

[brettw, 2011-08-22 23:40:45]

If you want stuff in .cc files to be exported from base.lib, you'll need to mark
them with BASE_EXPORT. Maybe you want to try that?

[Greg Spencer (Chromium), 2011-08-22 23:43:12]

On 2011/08/22 23:40:45, brettw wrote:
> If you want stuff in .cc files to be exported from base.lib, you'll need to
mark
> them with BASE_EXPORT. Maybe you want to try that?

OK, that explains things, thanks, but I think I actually prefer this CL: that
switch is really pretty unrelated to the code in base/.

[brettw, 2011-08-22 23:49:21]

That's fine. LGTM rubberstamp.

[stevenjb, 2011-08-22 23:56:55]

LGTM