This reverts commit 45afa562802ae9a253ef437dd0010c8c2ec17806.
Reason for revert: This was a workaround due to the kernel build
tools preserving the # nocheck comment as part of the config option
for CONFIG_PAGE_BLOCK_ORDER, which is problematic, since it is
supposed to be an int. The build tools have been patched to not
do that anymore, so this can be removed.
Bug: 424212284
Bug: 375647879
Bug: 355449177
Bug: 418282543
Change-Id: Ib999aea150c1c5f7f22ea6bdd81de0ec75f8efaf
[isaacmanjarres: resolved merge conflicts from PAGE_BLOCK_ORDER
being hardcoded to 8 on android14 kernels.]
Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com>
* commit '316b5982123009f55b59b3d95f3e2192c1e67ee7': (32 commits)
arm64: dts: rockchip: rv1126b-evb1/4-v10: Add "pmic-reset" for rk801
ARM: dts: rockchip: rk3506g-demo-display-control: Update system suspend config
mfd: rk801: Add support for pwrctrl active pol set and reboot rst
media: i2c: rk628: fix issue of incorrect calculation of dst_rate
media: i2c: rk628: add i2c write without lock
media: i2c: sc450ai support tb for v6.1
media: rockchip: vicap used ktime_get_boottime_ns for rv1126b to get timestamp
arm64: dts: rockchip: Add rv1126b-evb1-v10-amp.dts
ARM: dts: rockchip: Add rv1126-evb2-tb-400w board support
arm64: dts: rockchip: Add rv1126-evb2-tb-400w board support
media: rockchip: isp: fix enh for isp35
media: rockchip: isp: boottime for isp35
arm64: dts: rockchip: rk3576-iotest: fix property from 'gpio' to 'gpios'
ubi: Change to fill ec_hdr and vid_hdr redundant space with ff data on rockchip
arm64: dts: rockchip: rv1126b: Use cpu-thermal for npu opp table
mmc: core: Skip the first CMD1 when CONFIG_ROCKCHIP_THUNDER_BOOT_MMC=y
arm64: configs: Add rockchip_amp.config
arm64: dts: rockchip: Add RV1126B amp dtsi
i2c: rk3x: Fix DMA clean for Controllers without DMA
arm64: dts: rockchip: rv1126b: add clk_cpll_div10 assigned clk rate
...
Change-Id: I8837c893aab6c9e67667340e45bdf8937653acbd
This config will allow the 16kb page size kernels to have the
same CMA_MIN_ALIGNMENT_BYTES that 4k kernels. This means that
the CMA configs for the drivers won't have to change.
Note: This change is needed to avoid breaking old kernel
builds.
Bug: 424212284
Bug: 375647879
Bug: 355449177
Bug: 418282543
Test: tools/bazel run //common:kernel_aarch64_dist
tools/bazel run //common:kernel_aarch64_16k_dist
tools/bazel run //common:kernel_x86_64_dist
Change-Id: Icbfcab0d7e5ba18b3fc35c1186ef79e82f3e7ab1
Signed-off-by: Juan Yescas <jyescas@google.com>
Reset pmic and output NPOR signal 5ms when system reboot.
Change-Id: I8da3ee636faf193a7afcedae66daf7d12a883aa8
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
- Don't require pwrctrl dvs if hw compatible version >= 3.
- Auto parse pwrctrl active pol from GPIO_ACTIVE_{HIGH,LOW} flag.
- Reset pmic and soc when system reboot if required.
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
Change-Id: I29e60c2a717cee5c9d1e3c6e46ee687352d4a1be
Problem: On large page size configurations (16KiB, 64KiB), the CMA
alignment requirement (CMA_MIN_ALIGNMENT_BYTES) increases considerably,
and this causes the CMA reservations to be larger than necessary.
This means that system will have less available MIGRATE_UNMOVABLE and
MIGRATE_RECLAIMABLE page blocks since MIGRATE_CMA can't fallback to them.
The CMA_MIN_ALIGNMENT_BYTES increases because it depends on
MAX_PAGE_ORDER which depends on ARCH_FORCE_MAX_ORDER. The value of
ARCH_FORCE_MAX_ORDER increases on 16k and 64k kernels.
For example, in ARM, the CMA alignment requirement when:
- CONFIG_ARCH_FORCE_MAX_ORDER default value is used
- CONFIG_TRANSPARENT_HUGEPAGE is set:
PAGE_SIZE | MAX_PAGE_ORDER | pageblock_order | CMA_MIN_ALIGNMENT_BYTES
-----------------------------------------------------------------------
4KiB | 10 | 9 | 4KiB * (2 ^ 9) = 2MiB
16Kib | 11 | 11 | 16KiB * (2 ^ 11) = 32MiB
64KiB | 13 | 13 | 64KiB * (2 ^ 13) = 512MiB
There are some extreme cases for the CMA alignment requirement when:
- CONFIG_ARCH_FORCE_MAX_ORDER maximum value is set
- CONFIG_TRANSPARENT_HUGEPAGE is NOT set:
- CONFIG_HUGETLB_PAGE is NOT set
PAGE_SIZE | MAX_PAGE_ORDER | pageblock_order | CMA_MIN_ALIGNMENT_BYTES
------------------------------------------------------------------------
4KiB | 15 | 15 | 4KiB * (2 ^ 15) = 128MiB
16Kib | 13 | 13 | 16KiB * (2 ^ 13) = 128MiB
64KiB | 13 | 13 | 64KiB * (2 ^ 13) = 512MiB
This affects the CMA reservations for the drivers. If a driver in a
4KiB kernel needs 4MiB of CMA memory, in a 16KiB kernel, the minimal
reservation has to be 32MiB due to the alignment requirements:
reserved-memory {
...
cma_test_reserve: cma_test_reserve {
compatible = "shared-dma-pool";
size = <0x0 0x400000>; /* 4 MiB */
...
};
};
reserved-memory {
...
cma_test_reserve: cma_test_reserve {
compatible = "shared-dma-pool";
size = <0x0 0x2000000>; /* 32 MiB */
...
};
};
Solution: Add a new config CONFIG_PAGE_BLOCK_ORDER that
allows to set the page block order in all the architectures.
The maximum page block order will be given by
ARCH_FORCE_MAX_ORDER.
By default, CONFIG_PAGE_BLOCK_ORDER will have the same
value that ARCH_FORCE_MAX_ORDER. This will make sure that
current kernel configurations won't be affected by this
change. It is a opt-in change.
This patch will allow to have the same CMA alignment
requirements for large page sizes (16KiB, 64KiB) as that
in 4kb kernels by setting a lower pageblock_order.
Tests:
- Verified that HugeTLB pages work when pageblock_order is 1, 7, 10
on 4k and 16k kernels.
- Verified that Transparent Huge Pages work when pageblock_order
is 1, 7, 10 on 4k and 16k kernels.
- Verified that dma-buf heaps allocations work when pageblock_order
is 1, 7, 10 on 4k and 16k kernels.
Benchmarks:
The benchmarks compare 16kb kernels with pageblock_order 10 and 7. The
reason for the pageblock_order 7 is because this value makes the min
CMA alignment requirement the same as that in 4kb kernels (2MB).
- Perform 100K dma-buf heaps (/dev/dma_heap/system) allocations of
SZ_8M, SZ_4M, SZ_2M, SZ_1M, SZ_64, SZ_8, SZ_4. Use simpleperf
(https://developer.android.com/ndk/guides/simpleperf) to measure
the # of instructions and page-faults on 16k kernels.
The benchmark was executed 10 times. The averages are below:
# instructions | #page-faults
order 10 | order 7 | order 10 | order 7
--------------------------------------------------------
13,891,765,770 | 11,425,777,314 | 220 | 217
14,456,293,487 | 12,660,819,302 | 224 | 219
13,924,261,018 | 13,243,970,736 | 217 | 221
13,910,886,504 | 13,845,519,630 | 217 | 221
14,388,071,190 | 13,498,583,098 | 223 | 224
13,656,442,167 | 12,915,831,681 | 216 | 218
13,300,268,343 | 12,930,484,776 | 222 | 218
13,625,470,223 | 14,234,092,777 | 219 | 218
13,508,964,965 | 13,432,689,094 | 225 | 219
13,368,950,667 | 13,683,587,37 | 219 | 225
-------------------------------------------------------------------
13,803,137,433 | 13,131,974,268 | 220 | 220 Averages
There were 4.85% #instructions when order was 7, in comparison
with order 10.
13,803,137,433 - 13,131,974,268 = -671,163,166 (-4.86%)
The number of page faults in order 7 and 10 were the same.
These results didn't show any significant regression when the
pageblock_order is set to 7 on 16kb kernels.
- Run speedometer 3.1 (https://browserbench.org/Speedometer3.1/) 5 times
on the 16k kernels with pageblock_order 7 and 10.
order 10 | order 7 | order 7 - order 10 | (order 7 - order 10) %
-------------------------------------------------------------------
15.8 | 16.4 | 0.6 | 3.80%
16.4 | 16.2 | -0.2 | -1.22%
16.6 | 16.3 | -0.3 | -1.81%
16.8 | 16.3 | -0.5 | -2.98%
16.6 | 16.8 | 0.2 | 1.20%
-------------------------------------------------------------------
16.44 16.4 -0.04 -0.24% Averages
The results didn't show any significant regression when the
pageblock_order is set to 7 on 16kb kernels.
Signed-off-by: Juan Yescas <jyescas@google.com>
Acked-by: Zi Yan <ziy@nvidia.com>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit e13e7922d03439e374c263049af5f740ceae6346 https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/ mm-stable)
Bug: 375647879
Bug: 355449177
Bug: 418282543
[jyescas: Use MAX_ORDER instead of MAX_PAGE_ORDER. Update the file
mm/page_alloc.c instead of mm/mm_init.c due the function
set_pageblock_order is there.]
Test: Built and ran kernel
Link: https://lkml.kernel.org/r/20250521215807.1860663-1-jyescas@google.com
Change-Id: Id7132b6848e5deb97a7531cf546060de2accffac
This is use for battery-ipc application with 400w resolution camera
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Change-Id: I5ff04f3063468d4fe60202a1a98003dfb8c870a2
