No description
  • C 98.2%
  • Assembly 1%
  • Makefile 0.3%
  • Shell 0.2%
  • Python 0.1%
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Johannes Weiner 6c0600ad29
UPSTREAM: mm: memcontrol: recursive memory.low protection
Right now, the effective protection of any given cgroup is capped by its
own explicit memory.low setting, regardless of what the parent says.  The
reasons for this are mostly historical and ease of implementation: to make
delegation of memory.low safe, effective protection is the min() of all
memory.low up the tree.

Unfortunately, this limitation makes it impossible to protect an entire
subtree from another without forcing the user to make explicit protection
allocations all the way to the leaf cgroups - something that is highly
undesirable in real life scenarios.

Consider memory in a data center host.  At the cgroup top level, we have a
distinction between system management software and the actual workload the
system is executing.  Both branches are further subdivided into individual
services, job components etc.

We want to protect the workload as a whole from the system management
software, but that doesn't mean we want to protect and prioritize
individual workload wrt each other.  Their memory demand can vary over
time, and we'd want the VM to simply cache the hottest data within the
workload subtree.  Yet, the current memory.low limitations force us to
allocate a fixed amount of protection to each workload component in order
to get protection from system management software in general.  This
results in very inefficient resource distribution.

Another concern with mandating downward allocation is that, as the
complexity of the cgroup tree grows, it gets harder for the lower levels
to be informed about decisions made at the host-level.  Consider a
container inside a namespace that in turn creates its own nested tree of
cgroups to run multiple workloads.  It'd be extremely difficult to
configure memory.low parameters in those leaf cgroups that on one hand
balance pressure among siblings as the container desires, while also
reflecting the host-level protection from e.g.  rpm upgrades, that lie
beyond one or more delegation and namespacing points in the tree.

It's highly unusual from a cgroup interface POV that nested levels have to
be aware of and reflect decisions made at higher levels for them to be
effective.

To enable such use cases and scale configurability for complex trees, this
patch implements a resource inheritance model for memory that is similar
to how the CPU and the IO controller implement work-conserving resource
allocations: a share of a resource allocated to a subree always applies to
the entire subtree recursively, while allowing, but not mandating,
children to further specify distribution rules.

That means that if protection is explicitly allocated among siblings,
those configured shares are being followed during page reclaim just like
they are now.  However, if the memory.low set at a higher level is not
fully claimed by the children in that subtree, the "floating" remainder is
applied to each cgroup in the tree in proportion to its size.  Since
reclaim pressure is applied in proportion to size as well, each child in
that tree gets the same boost, and the effect is neutral among siblings -
with respect to each other, they behave as if no memory control was
enabled at all, and the VM simply balances the memory demands optimally
within the subtree.  But collectively those cgroups enjoy a boost over the
cgroups in neighboring trees.

E.g.  a leaf cgroup with a memory.low setting of 0 no longer means that
it's not getting a share of the hierarchically assigned resource, just
that it doesn't claim a fixed amount of it to protect from its siblings.

This allows us to recursively protect one subtree (workload) from another
(system management), while letting subgroups compete freely among each
other - without having to assign fixed shares to each leaf, and without
nested groups having to echo higher-level settings.

The floating protection composes naturally with fixed protection.
Consider the following example tree:

		A            A: low = 2G
               / \          A1: low = 1G
              A1 A2         A2: low = 0G

As outside pressure is applied to this tree, A1 will enjoy a fixed
protection from A2 of 1G, but the remaining, unclaimed 1G from A is split
evenly among A1 and A2, coming out to 1.5G and 0.5G.

There is a slight risk of regressing theoretical setups where the
top-level cgroups don't know about the true budgeting and set bogusly high
"bypass" values that are meaningfully allocated down the tree.  Such
setups would rely on unclaimed protection to be discarded, and
distributing it would change the intended behavior.  Be safe and hide the
new behavior behind a mount option, 'memory_recursiveprot'.

Change-Id: I7935aa5271093d4b84a5ce0deeda9593ea0ac4ee
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Roman Gushchin <guro@fb.com>
Acked-by: Chris Down <chris@chrisdown.name>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Michal Koutný <mkoutny@suse.com>
Link: http://lkml.kernel.org/r/20200227195606.46212-4-hannes@cmpxchg.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-01-14 18:13:12 -08:00
android
arch UPSTREAM: bpf: Handle return value of BPF_PROG_TYPE_STRUCT_OPS prog 2026-01-14 18:12:57 -08:00
block
certs
crypto BACKPORT: crypto: lib/sha1 - rename "sha" to "sha1" 2025-12-23 13:36:17 -08:00
Documentation UPSTREAM: mm: memcontrol: recursive memory.low protection 2026-01-14 18:13:12 -08:00
drivers UPSTREAM: module: Fix up module_notifier return values 2026-01-14 18:12:53 -08:00
fs UPSTREAM: kernfs: Add option to enable user xattrs 2026-01-14 18:13:12 -08:00
include UPSTREAM: mm: memcontrol: recursive memory.low protection 2026-01-14 18:13:12 -08:00
init UPSTREAM: bpf: Restrict bpf_probe_read{, str}() only to archs where they work 2026-01-14 18:12:54 -08:00
ipc BACKPORT: sysctl: pass kernel pointers to ->proc_handler 2025-12-23 13:36:15 -08:00
kernel UPSTREAM: mm: memcontrol: recursive memory.low protection 2026-01-14 18:13:12 -08:00
lib BACKPORT: bpf: Restrict bpf_trace_printk()'s %s usage and add %pks, %pus specifier 2026-01-14 18:12:53 -08:00
LICENSES
mm UPSTREAM: mm: memcontrol: recursive memory.low protection 2026-01-14 18:13:12 -08:00
net UPSTREAM: bpf: Fix bpf_sk_select_reuseport() memory leak 2026-01-14 18:13:11 -08:00
samples
scripts UPSTREAM: bpf: Fix bpf_redirect_neigh helper api to support supplying nexthop 2026-01-14 18:12:45 -08:00
security UPSTREAM: bpf: Implement bpf_local_storage for inodes 2026-01-14 18:12:21 -08:00
sound BACKPORT: mm: remove the pgprot argument to __vmalloc 2026-01-14 17:48:09 -08:00
techpack
tools BACKPORT: bpf: Allow reads from uninit stack 2026-01-14 18:13:10 -08:00
usr
virt
.clang-format
.cocciconfig
.get_maintainer.ignore
.gitattributes
.gitignore
.mailmap
Android.mk
Androidbp
build.config.aarch64
build.config.allmodconfig
build.config.allmodconfig.aarch64
build.config.allmodconfig.arm
build.config.allmodconfig.x86_64
build.config.arm
build.config.common
build.config.db845c
build.config.gki
build.config.gki-debug.aarch64
build.config.gki-debug.x86_64
build.config.gki.aarch64
build.config.gki.x86_64
build.config.gki_kasan
build.config.gki_kasan.aarch64
build.config.gki_kasan.x86_64
build.config.gki_kprobes
build.config.gki_kprobes.aarch64
build.config.gki_kprobes.x86_64
build.config.hikey960
build.config.msm.common
build.config.msm.gki
build.config.msm.lahaina
build.config.x86_64
build.targets
COPYING
CREDITS
gen_headers_arm.bp
gen_headers_arm64.bp
gen_headers_arm64_auto.bp
gen_headers_arm_auto.bp
Kbuild
Kconfig
kernel_headers.py
LICENSE
MAINTAINERS BACKPORT: bpf: Introduce BPF_PROG_TYPE_LSM 2025-12-23 13:36:09 -08:00
Makefile BACKPORT: bpf: Resolve BTF IDs in vmlinux image 2026-01-14 18:12:02 -08:00
modules.list.msm.lahaina
OWNERS
README
README.md

How do I submit patches to Android Common Kernels

  1. BEST: Make all of your changes to upstream Linux. If appropriate, backport to the stable releases. These patches will be merged automatically in the corresponding common kernels. If the patch is already in upstream Linux, post a backport of the patch that conforms to the patch requirements below.

  2. LESS GOOD: Develop your patches out-of-tree (from an upstream Linux point-of-view). Unless these are fixing an Android-specific bug, these are very unlikely to be accepted unless they have been coordinated with kernel-team@android.com. If you want to proceed, post a patch that conforms to the patch requirements below.

Common Kernel patch requirements

  • All patches must conform to the Linux kernel coding standards and pass script/checkpatch.pl
  • Patches shall not break gki_defconfig or allmodconfig builds for arm, arm64, x86, x86_64 architectures (see https://source.android.com/setup/build/building-kernels)
  • If the patch is not merged from an upstream branch, the subject must be tagged with the type of patch: UPSTREAM:, BACKPORT:, FROMGIT:, FROMLIST:, or ANDROID:.
  • All patches must have a Change-Id: tag (see https://gerrit-review.googlesource.com/Documentation/user-changeid.html)
  • If an Android bug has been assigned, there must be a Bug: tag.
  • All patches must have a Signed-off-by: tag by the author and the submitter

Additional requirements are listed below based on patch type

Requirements for backports from mainline Linux: UPSTREAM:, BACKPORT:

  • If the patch is a cherry-pick from Linux mainline with no changes at all
    • tag the patch subject with UPSTREAM:.
    • add upstream commit information with a (cherry-picked from ...) line
    • Example:
      • if the upstream commit message is
        important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>
    - then Joe Smith would upload the patch for the common kernel as
        UPSTREAM: important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>

        Bug: 135791357
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        (cherry-picked from c31e73121f4c1ec41143423ac6ce3ce6dafdcec1)
        Signed-off-by: Joe Smith <joe.smith@foo.org>
  • If the patch requires any changes from the upstream version, tag the patch with BACKPORT: instead of UPSTREAM:.
    • use the same tags as UPSTREAM:
    • add comments about the changes under the (cherry-picked from ...) line
    • Example:
        BACKPORT: important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>

        Bug: 135791357
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        (cherry-picked from c31e73121f4c1ec41143423ac6ce3ce6dafdcec1)
        [ Resolved minor conflict in drivers/foo/bar.c ]
        Signed-off-by: Joe Smith <joe.smith@foo.org>

Requirements for other backports: FROMGIT:, FROMLIST:,

  • If the patch has been merged into an upstream maintainer tree, but has not yet been merged into Linux mainline
    • tag the patch subject with FROMGIT:
    • add info on where the patch came from as (cherry picked from commit <sha1> <repo> <branch>). This must be a stable maintainer branch (not rebased, so don't use linux-next for example).
    • if changes were required, use BACKPORT: FROMGIT:
    • Example:
      • if the commit message in the maintainer tree is
        important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>
    - then Joe Smith would upload the patch for the common kernel as
        FROMGIT: important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>

        Bug: 135791357
        (cherry picked from commit 878a2fd9de10b03d11d2f622250285c7e63deace
         https://git.kernel.org/pub/scm/linux/kernel/git/foo/bar.git test-branch)
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        Signed-off-by: Joe Smith <joe.smith@foo.org>
  • If the patch has been submitted to LKML, but not accepted into any maintainer tree
    • tag the patch subject with FROMLIST:
    • add a Link: tag with a link to the submittal on lore.kernel.org
    • if changes were required, use BACKPORT: FROMLIST:
    • Example:
        FROMLIST: important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>

        Bug: 135791357
        Link: https://lore.kernel.org/lkml/20190619171517.GA17557@someone.com/
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        Signed-off-by: Joe Smith <joe.smith@foo.org>

Requirements for Android-specific patches: ANDROID:

  • If the patch is fixing a bug to Android-specific code
    • tag the patch subject with ANDROID:
    • add a Fixes: tag that cites the patch with the bug
    • Example:
        ANDROID: fix android-specific bug in foobar.c

        This is the detailed description of the important fix

        Fixes: 1234abcd2468 ("foobar: add cool feature")
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        Signed-off-by: Joe Smith <joe.smith@foo.org>
  • If the patch is a new feature
    • tag the patch subject with ANDROID:
    • add a Bug: tag with the Android bug (required for android-specific features)

Vibrator driver for HHG device

How to merge the driver into kernel source tree

  1. Copy ${this_project}/drivers/hid/hid-aksys.c into ${your_kernel_root}/drivers/hid/

  2. Compare and merge ${this_project}/drivers/hid/hid-ids.h into ${your_kernel_root}/drivers/hid/hid-ids.h : Add the following code before the last line of this file

    	#define USB_VENDER_ID_QUALCOMM  0x0a12
    	#define USB_VENDER_ID_TEMP_HHG_AKSY 0x1234
    	#define USB_PRODUCT_ID_AKSYS_HHG  0x1000
    
  3. Merge ${this_project}/drivers/hid/Kconfig into ${your_kernel_root}/drivers/hid/Kconfig : Add the following code before the last line of this file

    config HID_AKSYS_QRD
    	tristate "AKSys gamepad USB adapter support"
    	depends on HID
    	---help---
    	Support for AKSys gamepad USB adapter
    
    config AKSYS_QRD_FF
    	bool "AKSys gamepad USB adapter force feedback support"
    	depends on HID_AKSYS_QRD
    	select INPUT_FF_MEMLESS
    	---help---
    	Say Y here if you have a AKSys gamepad USB adapter and want to
    	enable force feedback support for it.
    
  4. Merge ${this_project}/drivers/hid/Makefile into ${your_kernel_root}/drivers/hid/Makefile : Add the following code at the end of this file

    obj-$(CONFIG_HID_AKSYS_QRD)	+= hid-aksys.o
    
  5. Modify your kernel's default build configuration file. Add the following two lines:

    CONFIG_HID_AKSYS_QRD=m
    CONFIG_AKSYS_QRD_FF=y