Chromium

Should this be backported to 29?

Re: #1

Yes, please.

yes, requesting merge, this should help with some of the jank cases with excessive swapping

Please attach a CL.

[Empty comment from Monorail migration]

Do we have any data on how this improves things for canary users?  Is this specific to any boards?

The page-cluster change is not specific to any boards, and it will only affect users who are using a lot of memory, to the point where they start to swap continually.  From the UMA stats we know that most users aren't using a lot of swap, but we have gotten some reports of excessive jank recently and excessive swapping is implicated in at least some of them.

I'm currently working on more instrumentation/metrics to measure when users get into that kind of trouble with swap, and I discovered this issue along the way when my tests to create a certain rate of expected swapping started seeing a great deal more than expected.  I've observed on my own parrot machine that with this change I'm able to use more memory without jank than without the change.

[Empty comment from Monorail migration]

Project: chromiumos/overlays/chromiumos-overlay
Branch : master
Author : Sonny Rao <sonnyrao@chromium.org>
Commit : 250ad0cbdbfc943336833a5370361d122f468a62

Code Review +2: Olof Johansson, Sonny Rao
Verified    +1: Sonny Rao
Change-Id     : Icf91e5cf48fb241315065ca601a3a7b5e143e69d
Reviewed-at   : https://gerrit.chromium.org/gerrit/63112

sysctl.conf: disable swap read-ahead

This sets the page-cluster tunable down from 2^3 pages of swap
read-ahead to 2^0 or no swap readahead.  Empirically, I've observed
that the high default leads to excessive swap-in and memory wastage.

BUG=chromium:263561
TEST=system boots and /proc/sys/vm/page-cluster is 0

Commit-Queue: Sonny Rao <sonnyrao@chromium.org>

D  chromeos-base/chromeos-base/chromeos-base-0-r76.ebuild
A  chromeos-base/chromeos-base/chromeos-base-0-r77.ebuild
M  chromeos-base/chromeos-base/files/sysctl.conf

Is this something we absolutely need for 29?  This seems like tuning, and not really stabilization.  29 is currently pretty unstable, and I'm only interesting in improving that before going to stable.  If there is another reason that this is urgent to get into 29, please wait until we see this on a 30 dev channel release.

Also implicated in  https://b.corp.google.com/issue?id=9886869

Wrong issue, apologies.

It certainly is tuning although in extreme cases the system can become unresponsive for seconds at a time.  I'm fine with waiting for an R30 dev to happen first.

Hey guys,
First of all, after much discussion for those who support this, I'm approving this CL for 29.
Secondly, the other TPMs and I have been working on trying to formalize what category of fixes we accept into our branches for each phase of the release process.  While I'm of the opinion that the class of fixes that this lies, which is to say 'nice to have' or 'not a regression', is something that we shouldn't even consider post branch.  The expectation is that a branch is feature complete, with only reverts, stability and security fixes and some tweaks to new features prior to beta.  Since we're post-beta, I've been resistant to accepting this from a process perspective.  I cannot speak to this from a user standpoint as others are better versed than I am.
Until the TPMs all agree to a set of guidelines, I felt it was unfair to be more restrictive than others based on my opinions.
That said - please consider the implication of the CLs you're landing on a release branch for the greater Chrome team as well as the end users.  The process is not meant to get in the way, but to allow us to ship very stable, security, speedy and simple to use product at a rapid rate.  Any change introduces unknowns.  By limiting the changeset to just things we think will improve 1+ of the 4 S's, we limit the unknowns.  This saves the whole team a lot of time and effort and allows us to move faster, as less bugs on release branches = less bug fixing on release branches = more great work on ToT.

Project: chromiumos/overlays/chromiumos-overlay
Branch : release-R29-4319.B
Author : Sonny Rao <sonnyrao@chromium.org>
Commit : 6af6388c61d9c686981c591593291e821bb9d7c9

Code Review  +2: Puneet Kumar
Verified     +1: Sonny Rao
Commit Queue   : Chumped
Change-Id      : Icf91e5cf48fb241315065ca601a3a7b5e143e69d
Reviewed-at    : https://gerrit.chromium.org/gerrit/63438

sysctl.conf: disable swap read-ahead

This sets the page-cluster tunable down from 2^3 pages of swap
read-ahead to 2^0 or no swap readahead.  Empirically, I've observed
that the high default leads to excessive swap-in and memory wastage.

BUG=chromium:263561
TEST=system boots and /proc/sys/vm/page-cluster is 0

Commit-Queue: Sonny Rao <sonnyrao@chromium.org>

D  chromeos-base/chromeos-base/chromeos-base-0-r75.ebuild
A  chromeos-base/chromeos-base/chromeos-base-0-r76.ebuild
M  chromeos-base/chromeos-base/files/sysctl.conf

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

This issue was migrated from crbug.com/chromium/263561?no_tracker_redirect=1

[Auto-CCs applied]