It is not common, but defining an overlapped region is possible.
Actually memblock_add_range allows to overlap with existing ones.
The memsize currently does not handle this overlapped case. But this
patch tries to handle one overlapped case.
Here's the case.
There is an unknown memsize region, which means the region was removed
and not passed at bootloader stage. And there is a reserved memory
region defined in device tree which is overlapped with the unknown
region.
We expect that information in device tree make the unknown region clear.
This patch handle the overlapped region with following conditions.
1) The already existing overlapped region should be unknown and no-map.
2) The newly added region should have a name, and its region should be
same with or part of the existing one.
Here is an example.
Before this patch, memsize shows both overlapped region.
0x0ea000000-0x0ed900000 0x03900000 ( 58368 KB ) nomap unusable overlapped
0x0ea000000-0x0f1400000 0x07400000 ( 118784 KB ) nomap unusable unknown
After this patch, the overlapped region is named.
0x0ea000000-0x0ed900000 0x03900000 ( 58368 KB ) nomap unusable overlapped
0x0e9b00000-0x0ea000000 0x00500000 ( 5120 KB ) nomap unusable unknown
Bug: 340432773
Signed-off-by: Jaewon Kim <jaewon31.kim@samsung.com>
Link: https://lore.kernel.org/linux-mm/20240521023957.2587005-4-jaewon31.kim@samsung.com/
Change-Id: I7091eedcebd1f2f771124c157e5e00600b9a36fd
These are disabled in the kernel already, so it's pointless to have them here.
This time we keep dss on, because otherwise last_kmsg stops working.
Signed-off-by: Nahuel Gómez <nahuelgomez329@gmail.com>
These labels are based on observations from a running system as well as
from inspecting the code:
!delayed_work_pending:
true = 3509732
false = 7495535
!need_update:
true = 6656251
false = 840000
Signed-off-by: Danny Lin <danny@kdrag0n.dev>
Signed-off-by: Tashfin Shakeer Rhythm <tashfinshakeerrhythm@gmail.com>
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
(cherry picked from commit 52e60a930f0480f2082bc65836c7edb4861de7aa)
(cherry picked from commit bb05861a4f3bb99b76e7e43ba17f3659fcb12443)
(cherry picked from commit d92be4aa5222a52104bed81fe60c5c10a091b4c1)
Signed-off-by: Samuel Pascua <sgpascua@ngcp.ph>
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
We don't want sched_nr_migrate to be too high, as that would impact
real-time latencies as the load balancing process for SCHED_OTHER
disallows IRQ interrupts.
Instead of making this a constant value, let's use an amount that
relates to the CPU performance of a device.
Consider that a device with a very weak 4 core processor needs to load
balance 32 tasks from the most busy-but-idle CPU. That balancing would
take significantly longer than a device with 8 cores.
On the contrary view, that same 8 core device balancing 32 tasks would
have no issues with SCHED_OTHER performance, however, real-time tasks
would suffer more jitter than is necessary.
Let's only balance as many tasks as there are CPUs in a device for
optimal SCHED_OTHER performance and SCHED_FIFO / SCHED_RR latency.
Freezing processes on Android usually takes less than 100 ms, and if it
takes longer than that to the point where the 20 second freeze timeout is
reached, it's because the remaining processes to be frozen are deadlocked
waiting for something from a process which is already frozen. There's no
point in burning power trying to freeze for that long, so reduce the freeze
timeout to a very generous 1 second for Android and don't let anything mess
with it.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Signed-off-by: Panchajanya1999 <kernel@panchajanya.dev>
(cherry picked from commit 72fc44bd8bcfb6d1cbaafb2053173cd985d81d0c)
(cherry picked from commit 7097f6cabd228cf426da77ee71088e56beba3cd0)
(cherry picked from commit 4f1c2d26818d846c0aea6713652e2a0eaa6a23c4)
(cherry picked from commit d416b35f8187c0605ac8816e4d771288514876f1)
