Add a hook in irqtime_account_process_tick, which helps to get
information about the high load task.
Bug: 187904818
Change-Id: I644f7d66b09d047ca6b0a0fbd2915a6387c8c007
Signed-off-by: Liangliang Li <liliangliang@vivo.com>
Currently, most of the thermal_zones are IRQ capable and they do not need
to be updated while resuming. To improve the system performance and reduce
the resume time. Add a vendor function to check if the thermal_zone is
not IRQ capable and needs to be updated.
Bug: 170905417
Test: boot and vendor function worked properly.
Change-Id: I9389985bba29b551a7a20b55e1ed26b6c4da9b3d
Signed-off-by: David Chao <davidchao@google.com>
"dev_name" for I2C devices won't have any value set, unless they are
instantiated thru ACPI interface. As a result of this, I2C driver will
assign some dynamic name in the format "%d-%04x" (e.g. 1-001f), and
further this device names are used for kernel wakelocks.
This dynamic names are difficult to associate with actual device and
hence it will help to have an ability where vendor can assign the
device name through vendor hooks.
Bug: 147496295
Signed-off-by: Manish Varma <varmam@google.com>
Change-Id: Idb417ef5330002063a9763544f9f0364f9581276
We already applied the 'vendor hook' for Dtask Debugging Information
in below issue.
(https://issuetracker.google.com/issues/162776704)
There are vendor hook call in mutex and rw_semaphore, but not for rt_mutex
Please refer to description in details as below,
1. Description
This feature writes rt mutex lock waiting information
on the task_struct structure. We can check mutex information and
mutex owner through the kernel log and custom analysis tools.
Like the previous feature in mutex and rw semaphore,
added data can be checked by ramdump analysis.
2. Vendor Hook Position
1) VENDOR_DATA
- struct task_struct in sched.h
VENDOR_DATA_ARRAY(2)
[0] : type // RTmutex (Mutex, Rwsem, ...)
[1] : pointer // address of lock
2) VENDOR_HOOKs
- __rt_mutex_slowlock() in kernel/locking/rtmutex.c
3. Example
- SysRq-w in kernel log
...
[ 54.164463] [3: kworker/u16:3: 253] kworker/3:2 D12736 418 2 0x00000228
[ 54.164497] [3: kworker/u16:3: 253] RTmutex: 0xffffffc051fa3ae8: owner[sh :9003]
[ 54.167812] [3: kworker/u16:3: 253] sh D12848 9003 6900 0x04000200
[ 54.167824] [3: kworker/u16:3: 253] RTmutex: 0xffffffc051fa3b08: owner[kworker/3:2 :418]
...
Bug: 186567468
Signed-off-by: JINHO LIM <jordan.lim@samsung.com>
Change-Id: I93f9753be0b2c1fa1a6eaea09379d54c31d1ebcf
(cherry picked from commit e289faa9f1)
Add a vendor hook for modules to know when the topology
code has determined the max capacity of cpus.
Bug: 187234873
Change-Id: Ia3e22479059d2e57500cbdd46504aa4773af6e4a
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
In Android GKI, CONFIG_FAIR_GROUP_SCHED is enabled [1] to help
prioritize important work. Given that CPU shares of root cgroup
can't be changed, leaving the tasks inside root cgroup will give
them higher share compared to the other tasks inside important
cgroups. This is mitigated by moving all tasks inside root cgroup to
a different cgroup after Android is booted. However, there are many
kernel tasks stuck in the root cgroup after the boot.
It is possible to relax kernel threads and kworkers migrations under
certain scenarios. However the patch [2] posted at upstream is not
accepted. Hence add a restricted vendor hook to notify modules when a
kernel thread is requested for cgroup migration. The modules can relax
the restrictions forced by the kernel and allow the cgroup migration.
[1] f08f049de1
[2] https://lore.kernel.org/lkml/1617714261-18111-1-git-send-email-pkondeti@codeaurora.org
Bug: 184594949
Change-Id: I445a170ba797c8bece3b4b59b7a42cdd85438f1f
Signed-off-by: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
Fix the following build warning:
include/trace/hooks/psi.h:17:18: warning: declaration of
'struct psi_trigger' will not be visible outside of
this function [-Wvisibility]
Bug: 178721511
Fixes: commit b79d1815c4 ("ANDROID: psi: Add vendor hooks for PSI tracing")
Change-Id: I4c8c9730f5a0c94fa8d93c6995ce25f385b52043
Signed-off-by: Georgi Djakov <quic_c_gdjako@quicinc.com>
When servicemanager process added service proxy from other process
register the service, we want to know the matching relation between
handle in the process and service name. When binder transaction
happened, We want to know what process calls what method on what service.
Bug: 186604985
Signed-off-by: zhengding chen <chenzhengding@oppo.com>
Change-Id: I813d1cde10294d8665f899f7fef0d444ec1f1f5e
Add vendor hook for selinux_state, so we can know
if the selinux_state is initialized
Bug: 186363840
Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
Change-Id: Ideed051a1d53ed1bce7d7915e38366264a7d77eb
Add vh before and after __update_load_avg_se
in order to collect load change of tasks.
Bug: 185557444
Change-Id: I210973f7e388164b68ed766074d1420cdf9d4c32
Signed-off-by: JianMin Liu <jian-min.liu@mediatek.com>
add vendor hooks to compute new cpu freq for oem feature.
Bug: 183674818
Signed-off-by: lijianzhong <lijianzhong@xiaomi.com>
Change-Id: I232d2e1ae885d6736eca9e4709870f4272b4873d
add vendor hooks for cpu affinity to support oem's feature.
Bug: 183674818
Signed-off-by: lijianzhong <lijianzhong@xiaomi.com>
Change-Id: I3402abec4d9faa08f564409bfb8db8d7902f3aa2
Add hooks to capture various per-zone memory stats when
a trigger threshold is hit.
Bug: 178721511
Change-Id: Ibe39263ddb05ffc3fa63b5225497a90c6480c8d7
Signed-off-by: Georgi Djakov <quic_c_gdjako@quicinc.com>
Initial kernel bootup logs get overwritten after running
for a long time, and there can be debugging scenario where
we need initial ~100s bootup logs for debugging.
'android_vh_initial_logbuf' vendor hook is helping in
achieving this purpose.
Bug: 185182649
Change-Id: I706824aeb566c09ecaf4b5900973d6cee8a2f35b
Signed-off-by: Mukesh Ojha <mojha@codeaurora.org>
android_rvh_check_preempt_wakeup hook is in place to allow vendor
modules to force the running task preemption by the waking task.
Update the tracepoint to accept another input to not preempting
the current running task. The hook is moved further down so that
it can be updated to pass the sched_entity structure corresponding
to waking and running tasks in the next patch.
Bug: 184575210
Change-Id: Id4f45ba2819802636b6b86ed34c124771d0d69eb
Signed-off-by: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
Add a restricted vendor hook to notify that a cpu controller
cgroup is online.
Bug: 184920911
Change-Id: I7d37f38c24ce146eabb4716a959aee703d71926e
Signed-off-by: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
Patch series "userfaultfd: add minor fault handling", v9.
Overview
========
This series adds a new userfaultfd feature, UFFD_FEATURE_MINOR_HUGETLBFS.
When enabled (via the UFFDIO_API ioctl), this feature means that any
hugetlbfs VMAs registered with UFFDIO_REGISTER_MODE_MISSING will *also*
get events for "minor" faults. By "minor" fault, I mean the following
situation:
Let there exist two mappings (i.e., VMAs) to the same page(s) (shared
memory). One of the mappings is registered with userfaultfd (in minor
mode), and the other is not. Via the non-UFFD mapping, the underlying
pages have already been allocated & filled with some contents. The UFFD
mapping has not yet been faulted in; when it is touched for the first
time, this results in what I'm calling a "minor" fault. As a concrete
example, when working with hugetlbfs, we have huge_pte_none(), but
find_lock_page() finds an existing page.
We also add a new ioctl to resolve such faults: UFFDIO_CONTINUE. The idea
is, userspace resolves the fault by either a) doing nothing if the
contents are already correct, or b) updating the underlying contents using
the second, non-UFFD mapping (via memcpy/memset or similar, or something
fancier like RDMA, or etc...). In either case, userspace issues
UFFDIO_CONTINUE to tell the kernel "I have ensured the page contents are
correct, carry on setting up the mapping".
Use Case
========
Consider the use case of VM live migration (e.g. under QEMU/KVM):
1. While a VM is still running, we copy the contents of its memory to a
target machine. The pages are populated on the target by writing to the
non-UFFD mapping, using the setup described above. The VM is still running
(and therefore its memory is likely changing), so this may be repeated
several times, until we decide the target is "up to date enough".
2. We pause the VM on the source, and start executing on the target machine.
During this gap, the VM's user(s) will *see* a pause, so it is desirable to
minimize this window.
3. Between the last time any page was copied from the source to the target, and
when the VM was paused, the contents of that page may have changed - and
therefore the copy we have on the target machine is out of date. Although we
can keep track of which pages are out of date, for VMs with large amounts of
memory, it is "slow" to transfer this information to the target machine. We
want to resume execution before such a transfer would complete.
4. So, the guest begins executing on the target machine. The first time it
touches its memory (via the UFFD-registered mapping), userspace wants to
intercept this fault. Userspace checks whether or not the page is up to date,
and if not, copies the updated page from the source machine, via the non-UFFD
mapping. Finally, whether a copy was performed or not, userspace issues a
UFFDIO_CONTINUE ioctl to tell the kernel "I have ensured the page contents
are correct, carry on setting up the mapping".
We don't have to do all of the final updates on-demand. The userfaultfd manager
can, in the background, also copy over updated pages once it receives the map of
which pages are up-to-date or not.
Interaction with Existing APIs
==============================
Because this is a feature, a registered VMA could potentially receive both
missing and minor faults. I spent some time thinking through how the
existing API interacts with the new feature:
UFFDIO_CONTINUE cannot be used to resolve non-minor faults, as it does not
allocate a new page. If UFFDIO_CONTINUE is used on a non-minor fault:
- For non-shared memory or shmem, -EINVAL is returned.
- For hugetlb, -EFAULT is returned.
UFFDIO_COPY and UFFDIO_ZEROPAGE cannot be used to resolve minor faults.
Without modifications, the existing codepath assumes a new page needs to
be allocated. This is okay, since userspace must have a second
non-UFFD-registered mapping anyway, thus there isn't much reason to want
to use these in any case (just memcpy or memset or similar).
- If UFFDIO_COPY is used on a minor fault, -EEXIST is returned.
- If UFFDIO_ZEROPAGE is used on a minor fault, -EEXIST is returned (or -EINVAL
in the case of hugetlb, as UFFDIO_ZEROPAGE is unsupported in any case).
- UFFDIO_WRITEPROTECT simply doesn't work with shared memory, and returns
-ENOENT in that case (regardless of the kind of fault).
Future Work
===========
This series only supports hugetlbfs. I have a second series in flight to
support shmem as well, extending the functionality. This series is more
mature than the shmem support at this point, and the functionality works
fully on hugetlbfs, so this series can be merged first and then shmem
support will follow.
This patch (of 6):
This feature allows userspace to intercept "minor" faults. By "minor"
faults, I mean the following situation:
Let there exist two mappings (i.e., VMAs) to the same page(s). One of the
mappings is registered with userfaultfd (in minor mode), and the other is
not. Via the non-UFFD mapping, the underlying pages have already been
allocated & filled with some contents. The UFFD mapping has not yet been
faulted in; when it is touched for the first time, this results in what
I'm calling a "minor" fault. As a concrete example, when working with
hugetlbfs, we have huge_pte_none(), but find_lock_page() finds an existing
page.
This commit adds the new registration mode, and sets the relevant flag on
the VMAs being registered. In the hugetlb fault path, if we find that we
have huge_pte_none(), but find_lock_page() does indeed find an existing
page, then we have a "minor" fault, and if the VMA has the userfaultfd
registration flag, we call into userfaultfd to handle it.
This is implemented as a new registration mode, instead of an API feature.
This is because the alternative implementation has significant drawbacks
[1].
However, doing it this was requires we allocate a VM_* flag for the new
registration mode. On 32-bit systems, there are no unused bits, so this
feature is only supported on architectures with
CONFIG_ARCH_USES_HIGH_VMA_FLAGS. When attempting to register a VMA in
MINOR mode on 32-bit architectures, we return -EINVAL.
[1] https://lore.kernel.org/patchwork/patch/1380226/
Link: https://lkml.kernel.org/r/20210301222728.176417-1-axelrasmussen@google.com
Link: https://lkml.kernel.org/r/20210301222728.176417-2-axelrasmussen@google.com
Signed-off-by: Axel Rasmussen <axelrasmussen@google.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chinwen Chang <chinwen.chang@mediatek.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jann Horn <jannh@google.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Lokesh Gidra <lokeshgidra@google.com>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: "Michal Koutn" <mkoutny@suse.com>
Cc: Michel Lespinasse <walken@google.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Peter Xu <peterx@redhat.com>
Cc: Shaohua Li <shli@fb.com>
Cc: Shawn Anastasio <shawn@anastas.io>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Steven Price <steven.price@arm.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Adam Ruprecht <ruprecht@google.com>
Cc: Axel Rasmussen <axelrasmussen@google.com>
Cc: Cannon Matthews <cannonmatthews@google.com>
Cc: "Dr . David Alan Gilbert" <dgilbert@redhat.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Mina Almasry <almasrymina@google.com>
Cc: Oliver Upton <oupton@google.com>
Cc: Kirill A. Shutemov <kirill@shutemov.name>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
(cherry picked from commit 82a150ec394f6b944e26786b907fc0deab5b2064
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm)
Link: https://lore.kernel.org/patchwork/patch/1388132/
Conflicts:
arch/arm64/Kconfig
fs/userfaultfd.c
mm/hugetlb.c
(All related to SPF feature. Resolved by manual rebase)
Signed-off-by: Lokesh Gidra <lokeshgidra@google.com>
Bug: 160737021
Bug: 169683130
Change-Id: I43b37272d531341439ceaa03213d0e2415e04688
Add vendor hook to get signal for vendor-specific tuning.
Bug: 184898838
Signed-off-by: Zhuguangqing <zhuguangqing@xiaomi.com>
Change-Id: I83a28b0a6eb413976f4c57f2314d008ad792fa0d
Vendor hook for making sinks comply to pSnkStby requirement.
Hook is an alternate to the following patch series:
https://patchwork.kernel.org/project/linux-usb/list/?series=461087
OOT_Bug:
Bug: 184607655
Bug: 168245874
Bug: 173252019
Bug: 162789342
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Change-Id: I39510690ed866cbbc74ef50a18136bf2d5a95aac
Add a hook after receiving the source capabilities from the partner
port. Pass the address of the source capability array so that vendor
code is able to access them.
OOT bug:
Bug: 181629276
Bug: 169215197
Signed-off-by: Kyle Tso <kyletso@google.com>
Change-Id: I11c4a7919c248690e63c3bfbebfa6b8d711175a6
linux/usb/pd.h has a bunch of timers for which the Type-C spec defines
a range of values. These values have to be tuned based on the latency
observed in a specific architecture. However, linux opensource sets
them to a specific value without providing a mechanism to set board
specific values. While a generic way is figured out, a vendor hook
is needed in the interim.
For instance, tCCDebounce can have a value between 100msec - 200msec.
OOT_bug:
Bug: 184308605
Bug: 168245874
Bug: 173252019
Change-Id: I278b34654a7e48990b6ebe25fbe17e3aa4165098
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
A vendor hook is added in post_init_entity_util_avg before
a new cfs task's util is attached to cfs_rq's util so that
vendors can gather and modify se's information to modify
scheduling behavior and DVFS as they want.
trace_android_rvh_new_task_stats is not a proper hook because
it is called after the task's util is attached to cfs_rq's util,
which means updating cfs_rq's sched_avg and DVFS request are done.
Bug: 184219858
Signed-off-by: Choonghoon Park <choong.park@samsung.com>
Change-Id: I2deaa93297f8464895978496c9838cdffaa35b7f
Allow up to two attachments to restricted vendor hooks to enable OEM
and vendor coexistence.
Priorities are not exposed to callers on purpose. Life's too short to
re-order the callback array with concurrent readers.
Bug: 183720636
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: I5c7aca7f69e581b4197388478d47e0da6d2893e6
Add vendor hook to get the binder message for vendor-specific tuning.
Bug: 182496370
Signed-off-by: Zhuguangqing <zhuguangqing@xiaomi.com>
Change-Id: Id47e59c4e3ccd07b26eef758ada147b98cd1964e
timerfd doesn't create any wakelocks, but eventpoll can. When it does,
it names them after the underlying file descriptor, and since all
timerfd file descriptors are named "[timerfd]" (which saves memory on
systems like desktops with potentially many timerfd instances), all
wakesources created as a result of using the eventpoll-on-timerfd idiom
are called... "[timerfd]".
However, it becomes impossible to tell which "[timerfd]" wakesource is
affliated with which process and hence troubleshooting is difficult.
Adding vendor hooks to allow vendor to assign appropriate names to
timerfd descriptors and eventoll wakesource.
Bug: 155142106
Signed-off-by: Manish Varma <varmam@google.com>
Change-Id: I330a42ab48bed4b26d5eb2f636925c66061165ec
Add a hook in account_process_tick, which help us to get information
about the high load task and the cpu they running on.
Bug: 183260319
Change-Id: I54162ce3c65bd69e08d2d4747e4d4883efe4c442
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
This hook is for addressing hardware anomalies where
TCPC_POWER_STATUS_VBUS_PRES bit can return 0 even before falling
below sSinkDisconnect threshold.
Handler has to set bypass to override the value that would otherwise
be returned by this function.
Handler can set vbus or clear vbus to indicate vbus present or absent
OOT_bug:
Bug: 183149028
Bug: 168245874
Bug: 173252019
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Change-Id: I2ca994d49b37bf8600c5913b892fde9acd0dc896
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Needed to implement chip specific features that are not defined
in the Type-C spec.
OOT_bug:
Bug: 169213252
Bug: 168245874
Bug: 173252019
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Change-Id: Ibd7b9171f105321c3010fb5b0a67d76a91224800
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Needed to implement chip specific features that are not defined
in the Type-C spec.
OOT_bug:
Bug: 169213252
Bug: 168245874
Bug: 173252019
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Change-Id: I36fe75dddd8cd4e2054db01ed4fee7ea08dd8702
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Remove the set_sugov_sched_attr hook which is no longer needed with a
modular governor. The IOWait hook must stay, however.
Bug: 171598214
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: Ie68df673bc78ca76c90ba1e6c32ecaa4bba10c89
