Enable PSI ftrace logging to collect ftrace information about
PSI events.
Change-Id: Ia4d786f5cbc242991fd0e0ecdb63d16714bffeb8
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Page replacement is handled in the Linux Kernel in one of two ways:
1) Asynchronously via kswapd
2) Synchronously, via direct reclaim
At page allocation time the allocating task is immediately given a page
from the zone free list allowing it to go right back to work doing
whatever it was doing; Probably directly or indirectly executing business
logic.
Just prior to satisfying the allocation, free pages is checked to see if
it has reached the zone low watermark and if so, kswapd is awakened.
Kswapd will start scanning pages looking for inactive pages to evict to
make room for new page allocations. The work of kswapd allows tasks to
continue allocating memory from their respective zone free list without
incurring any delay.
When the demand for free pages exceeds the rate that kswapd tasks can
supply them, page allocation works differently. Once the allocating task
finds that the number of free pages is at or below the zone min watermark,
the task will no longer pull pages from the free list. Instead, the task
will run the same CPU-bound routines as kswapd to satisfy its own
allocation by scanning and evicting pages. This is called a direct reclaim.
The time spent performing a direct reclaim can be substantial, often
taking tens to hundreds of milliseconds for small order0 allocations to
half a second or more for order9 huge-page allocations. In fact, kswapd is
not actually required on a linux system. It exists for the sole purpose of
optimizing performance by preventing direct reclaims.
When memory shortfall is sufficient to trigger direct reclaims, they can
occur in any task that is running on the system. A single aggressive
memory allocating task can set the stage for collateral damage to occur in
small tasks that rarely allocate additional memory. Consider the impact of
injecting an additional 100ms of latency when nscd allocates memory to
facilitate caching of a DNS query.
The presence of direct reclaims 10 years ago was a fairly reliable
indicator that too much was being asked of a Linux system. Kswapd was
likely wasting time scanning pages that were ineligible for eviction.
Adding RAM or reducing the working set size would usually make the problem
go away. Since then hardware has evolved to bring a new struggle for
kswapd. Storage speeds have increased by orders of magnitude while CPU
clock speeds stayed the same or even slowed down in exchange for more
cores per package. This presents a throughput problem for a single
threaded kswapd that will get worse with each generation of new hardware.
Test Details
NOTE: The tests below were run with shadow entries disabled. See the
associated patch and cover letter for details
The tests below were designed with the assumption that a kswapd bottleneck
is best demonstrated using filesystem reads. This way, the inactive list
will be full of clean pages, simplifying the analysis and allowing kswapd
to achieve the highest possible steal rate. Maximum steal rates for kswapd
are likely to be the same or lower for any other mix of page types on the
system.
Tests were run on a 2U Oracle X7-2L with 52 Intel Xeon Skylake 2GHz cores,
756GB of RAM and 8 x 3.6 TB NVMe Solid State Disk drives. Each drive has
an XFS file system mounted separately as /d0 through /d7. SSD drives
require multiple concurrent streams to show their potential, so I created
eleven 250GB zero-filled files on each drive so that I could test with
parallel reads.
The test script runs in multiple stages. At each stage, the number of dd
tasks run concurrently is increased by 2. I did not include all of the
test output for brevity.
During each stage dd tasks are launched to read from each drive in a round
robin fashion until the specified number of tasks for the stage has been
reached. Then iostat, vmstat and top are started in the background with 10
second intervals. After five minutes, all of the dd tasks are killed and
the iostat, vmstat and top output is parsed in order to report the
following:
CPU consumption
- sy - aggregate kernel mode CPU consumption from vmstat output. The value
doesn't tend to fluctuate much so I just grab the highest value.
Each sample is averaged over 10 seconds
- dd_cpu - for all of the dd tasks averaged across the top samples since
there is a lot of variation.
Throughput
- in Kbytes
- Command is iostat -x -d 10 -g total
This first test performs reads using O_DIRECT in order to show the maximum
throughput that can be obtained using these drives. It also demonstrates
how rapidly throughput scales as the number of dd tasks are increased.
The dd command for this test looks like this:
Command Used: dd iflag=direct if=/d${i}/$n of=/dev/null bs=4M
Test #1: Direct IO
dd sy dd_cpu throughput
6 0 2.33 14726026.40
10 1 2.95 19954974.80
16 1 2.63 24419689.30
22 1 2.63 25430303.20
28 1 2.91 26026513.20
34 1 2.53 26178618.00
40 1 2.18 26239229.20
46 1 1.91 26250550.40
52 1 1.69 26251845.60
58 1 1.54 26253205.60
64 1 1.43 26253780.80
70 1 1.31 26254154.80
76 1 1.21 26253660.80
82 1 1.12 26254214.80
88 1 1.07 26253770.00
90 1 1.04 26252406.40
Throughput was close to peak with only 22 dd tasks. Very little system CPU
was consumed as expected as the drives DMA directly into the user address
space when using direct IO.
In this next test, the iflag=direct option is removed and we only run the
test until the pgscan_kswapd from /proc/vmstat starts to increment. At
that point metrics are parsed and reported and the pagecache contents are
dropped prior to the next test. Lather, rinse, repeat.
Test #2: standard file system IO, no page replacement
dd sy dd_cpu throughput
6 2 28.78 5134316.40
10 3 31.40 8051218.40
16 5 34.73 11438106.80
22 7 33.65 14140596.40
28 8 31.24 16393455.20
34 10 29.88 18219463.60
40 11 28.33 19644159.60
46 11 25.05 20802497.60
52 13 26.92 22092370.00
58 13 23.29 22884881.20
64 14 23.12 23452248.80
70 15 22.40 23916468.00
76 16 22.06 24328737.20
82 17 20.97 24718693.20
88 16 18.57 25149404.40
90 16 18.31 25245565.60
Each read has to pause after the buffer in kernel space is populated while
those pages are added to the pagecache and copied into the user address
space. For this reason, more parallel streams are required to achieve peak
throughput. The copy operation consumes substantially more CPU than direct
IO as expected.
The next test measures throughput after kswapd starts running. This is the
same test only we wait for kswapd to wake up before we start collecting
metrics. The script actually keeps track of a few things that were not
mentioned earlier. It tracks direct reclaims and page scans by watching
the metrics in /proc/vmstat. CPU consumption for kswapd is tracked the
same way it is tracked for dd.
Since the test is 100% reads, you can assume that the page steal rate for
kswapd and direct reclaims is almost identical to the scan rate.
Test #3: 1 kswapd thread per node
dd sy dd_cpu kswapd0 kswapd1 throughput dr pgscan_kswapd pgscan_direct
10 4 26.07 28.56 27.03 7355924.40 0 459316976 0
16 7 34.94 69.33 69.66 10867895.20 0 872661643 0
22 10 36.03 93.99 99.33 13130613.60 489 1037654473 11268334
28 10 30.34 95.90 98.60 14601509.60 671 1182591373 15429142
34 14 34.77 97.50 99.23 16468012.00 10850 1069005644 249839515
40 17 36.32 91.49 97.11 17335987.60 18903 975417728 434467710
46 19 38.40 90.54 91.61 17705394.40 25369 855737040 582427973
52 22 40.88 83.97 83.70 17607680.40 31250 709532935 724282458
58 25 40.89 82.19 80.14 17976905.60 35060 657796473 804117540
64 28 41.77 73.49 75.20 18001910.00 39073 561813658 895289337
70 33 45.51 63.78 64.39 17061897.20 44523 379465571 1020726436
76 36 46.95 57.96 60.32 16964459.60 47717 291299464 1093172384
82 39 47.16 55.43 56.16 16949956.00 49479 247071062 1134163008
88 42 47.41 53.75 47.62 16930911.20 51521 195449924 1180442208
90 43 47.18 51.40 50.59 16864428.00 51618 190758156 1183203901
In the previous test where kswapd was not involved, the system-wide kernel
mode CPU consumption with 90 dd tasks was 16%. In this test CPU consumption
with 90 tasks is at 43%. With 52 cores, and two kswapd tasks (one per NUMA
node), kswapd can only be responsible for a little over 4% of the increase.
The rest is likely caused by 51,618 direct reclaims that scanned 1.2
billion pages over the five minute time period of the test.
Same test, more kswapd tasks:
Test #4: 4 kswapd threads per node
dd sy dd_cpu kswapd0 kswapd1 throughput dr pgscan_kswapd pgscan_direct
10 5 27.09 16.65 14.17 7842605.60 0 459105291 0
16 10 37.12 26.02 24.85 11352920.40 15 920527796 358515
22 11 36.94 37.13 35.82 13771869.60 0 1132169011 0
28 13 35.23 48.43 46.86 16089746.00 0 1312902070 0
34 15 33.37 53.02 55.69 18314856.40 0 1476169080 0
40 19 35.90 69.60 64.41 19836126.80 0 1629999149 0
46 22 36.82 88.55 57.20 20740216.40 0 1708478106 0
52 24 34.38 93.76 68.34 21758352.00 0 1794055559 0
58 24 30.51 79.20 82.33 22735594.00 0 1872794397 0
64 26 30.21 97.12 76.73 23302203.60 176 1916593721 4206821
70 33 32.92 92.91 92.87 23776588.00 3575 1817685086 85574159
76 37 31.62 91.20 89.83 24308196.80 4752 1812262569 113981763
82 29 25.53 93.23 92.33 24802791.20 306 2032093122 7350704
88 43 37.12 76.18 77.01 25145694.40 20310 1253204719 487048202
90 42 38.56 73.90 74.57 22516787.60 22774 1193637495 545463615
By increasing the number of kswapd threads, throughput increased by ~50%
while kernel mode CPU utilization decreased or stayed the same, likely due
to a decrease in the number of parallel tasks at any given time doing page
replacement.
Change-Id: I966d4a9c33bad188b3409f7ceea1df205a63c3bd
Signed-off-by: Buddy Lumpkin <buddy.lumpkin@oracle.com>
Patch-mainline: linux-mm @ Mon, 2 Apr 2018 09:24:22
Link: https://lore.kernel.org/lkml/1522661062-39745-1-git-send-email-buddy.lumpkin@oracle.com
[charante@codeaurora.org]: Changes done to ensure QGKI compliance.
Signed-off-by: Charan Teja Kalla <charante@codeaurora.org>
Some tpdm don't support cmb msr, add an option "qcom,cmb-msr-skip"
to indicate whether MSR is supported.
Change-Id: I8ae66e639fe68b236ad8a268b18acbda737a9d93
Signed-off-by: Yuanfang Zhang <zhangyuanfang@codeaurora.org>
uefi bootloader may not bring out the spss for all the
scenarios such as fastboot continue when device is flashed
first time. uefi sets rmb general purpose status register
when it failed to bring spss out of reset. So secure
pil driver checks the rmb general purpose register to find out
whether spss firmware is already loaded or not and updates the
.powerup function.
Change-Id: Iade37d6e0a8354b4178e2a4c1b36e90f024aeb84
Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
Callbacks with the backing dma fences are not registered
for composite (merged) synx objects.
Hence added check to exclude dma fence removal for the
merged objects during cleanup.
Also, the check for the synx object status is moved prior
to dma fence callback removal as any attempts to re-signal
a signaled object does not attempt to remove dma fence
callback again.
Change-Id: Idbbdf1d813ed1099d35044d2e454d60017fe172a
Signed-off-by: Sumukh Hallymysore Ravindra <shallymy@codeaurora.org>
Fixed the names of the SW_CTRL and Debug GPIOs in devicetree.
Change-Id: Ibdcc1164cd88a65fe5b33927f2b0f0098c15af1f
Signed-off-by: Umesh Vats <uvats@codeaurora.org>
UFS version 3.0 and later devices use Vcc and Vccq regulators
while UFS version 2.0 and 2.1 devices use Vcc and Vccq2 .
Properly set the device's supported Icc level for the
regulators used by the device.
Change-Id: I3e657d6167976706d69a582b3983df794102e3af
Signed-off-by: Bao D. Nguyen <nguyenb@codeaurora.org>
Enable CONFIG_USB_CONFIGFS_ACM and CONFIG_USB_CONFIGFS_F_HID as these
options were somehow not selected before.
Bug: 158724286
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I79c47a598601d2316fb3ff66d3eef8b6f0a6149e
This patch changes process_madvise interface:
a) support vector address ranges in a system call
b) support the vector address ranges to local process as well as
external process
c) remove pid but keep only pidfd in argument - [1][2]
d) change type of flags with unsgined int
Android app has thousands of vmas due to zygote so it's totally waste of
CPU and power if we should call the syscall one by one for each vma.
(With testing 2000-vma syscall vs 1-vector syscall, it showed 15%
performance improvement. I think it would be bigger in real practice
because the testing ran very cache friendly environment).
Another potential use case for the vector range is to amortize the cost of
TLB shootdowns for multiple ranges when using MADV_DONTNEED; this could
benefit users like TCP receive zerocopy and malloc implementations. In
future, we could find more usecases for other advises so let's make it
happens as API since we introduce a new syscall at this moment. With
that, existing madvise(2) user could replace it with process_madvise(2)
with their own pid if they want to have batch address ranges support
feature.
So finally, the API is as follows,
ssize_t process_madvise(int pidfd, const struct iovec *iovec,
unsigned long vlen, int advice, unsigned int flags);
DESCRIPTION
The process_madvise() system call is used to give advice or directions
to the kernel about the address ranges from external process as well as
local process. It provides the advice to address ranges of process
described by iovec and vlen. The goal of such advice is to improve system
or application performance.
The pidfd selects the process referred to by the PID file descriptor
specified in pidfd. (See pidofd_open(2) for further information)
The pointer iovec points to an array of iovec structures, defined in
<sys/uio.h> as:
struct iovec {
void *iov_base; /* starting address */
size_t iov_len; /* number of bytes to be advised */
};
The iovec describes address ranges beginning at address(iov_base)
and with size length of bytes(iov_len).
The vlen represents the number of elements in iovec.
The advice is indicated in the advice argument, which is one of the
following at this moment if the target process specified by pidfd is
external.
MADV_COLD
MADV_PAGEOUT
MADV_MERGEABLE
MADV_UNMERGEABLE
Permission to provide a hint to external process is governed by a
ptrace access mode PTRACE_MODE_ATTACH_FSCREDS check; see ptrace(2).
The process_madvise supports every advice madvise(2) has if target
process is in same thread group with calling process so user could
use process_madvise(2) to extend existing madvise(2) to support
vector address ranges.
RETURN VALUE
On success, process_madvise() returns the number of bytes advised.
This return value may be less than the total number of requested
bytes, if an error occurred. The caller should check return value
to determine whether a partial advice occurred.
[1] https://lore.kernel.org/linux-mm/20200509124817.xmrvsrq3mla6b76k@wittgenstein/
[2] https://lore.kernel.org/linux-mm/9d849087-3359-c4ab-fbec-859e8186c509@virtuozzo.com/
Link: http://lkml.kernel.org/r/20200518211350.GA50295@google.com
Link: http://lkml.kernel.org/r/20200423145215.72666-2-minchan@kernel.org
Signed-off-by: Minchan Kim <minchan@kernel.org>
Reviewed-by: Suren Baghdasaryan <surenb@google.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Arjun Roy <arjunroy@google.com>
Cc: Tim Murray <timmurray@google.com>
Cc: Daniel Colascione <dancol@google.com>
Cc: Sonny Rao <sonnyrao@google.com>
Cc: Brian Geffon <bgeffon@google.com>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: John Dias <joaodias@google.com>
Cc: Joel Fernandes <joel@joelfernandes.org>
Cc: SeongJae Park <sj38.park@gmail.com>
Cc: Oleksandr Natalenko <oleksandr@redhat.com>
Cc: Sandeep Patil <sspatil@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Git-Commit: cac63a8674fec9a9e288972475366896d706b53c
Git-Repo: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
From: Randy Dunlap <rdunlap@infradead.org>
Subject: mm-support-vector-address-ranges-for-process_madvise-fix-fix
fix process_madvise prototype.
[charante@codeaurora.org]: This is merged with cac63a8674fe ("mm:
support vector address ranges for process_madvise" to avoid the
compilation errors.
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Git-Commit: beadf725ea3f41cc23c77aefcb3139c081ff528d
Git-Repo: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Change-Id: I8aa28294d56874f057779674337986dbbe7cf076
Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
It all began with the fact that KSM works only on memory that is marked by
madvise(). And the only way to get around that is to either:
* use LD_PRELOAD; or
* patch the kernel with something like UKSM or PKSM.
(i skip ptrace can of worms here intentionally)
To overcome this restriction, lets employ a new remote madvise API. This
can be used by some small userspace helper daemon that will do auto-KSM
job for us.
I think of two major consumers of remote KSM hints:
* hosts, that run containers, especially similar ones and especially in
a trusted environment, sharing the same runtime like Node.js;
* heavy applications, that can be run in multiple instances, not
limited to opensource ones like Firefox, but also those that cannot be
modified since they are binary-only and, maybe, statically linked.
Speaking of statistics, more numbers can be found in the very first
submission, that is related to this one [1]. For my current setup with
two Firefox instances I get 100 to 200 MiB saved for the second instance
depending on the amount of tabs.
1 FF instance with 15 tabs:
$ echo "$(cat /sys/kernel/mm/ksm/pages_sharing) * 4 / 1024" | bc
410
2 FF instances, second one has 12 tabs (all the tabs are different):
$ echo "$(cat /sys/kernel/mm/ksm/pages_sharing) * 4 / 1024" | bc
592
At the very moment I do not have specific numbers for containerised
workload, but those should be comparable in case the containers share
similar/same runtime.
[1] https://lore.kernel.org/patchwork/patch/1012142/.
Change-Id: I325b1ec4ee73fe03511391a687a6ecc4c5df89e7
Link: http://lkml.kernel.org/r/20200302193630.68771-8-minchan@kernel.org
Signed-off-by: Oleksandr Natalenko <oleksandr@redhat.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Reviewed-by: SeongJae Park <sjpark@amazon.de>
Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Cc: Brian Geffon <bgeffon@google.com>
Cc: Christian Brauner <christian@brauner.io>
Cc: Daniel Colascione <dancol@google.com>
Cc: Jann Horn <jannh@google.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Joel Fernandes <joel@joelfernandes.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: John Dias <joaodias@google.com>
Cc: Kirill Tkhai <ktkhai@virtuozzo.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Sandeep Patil <sspatil@google.com>
Cc: SeongJae Park <sj38.park@gmail.com>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Sonny Rao <sonnyrao@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Tim Murray <timmurray@google.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Christian Brauner <christian.brauner@ubuntu.com>
Cc: <linux-man@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Git-Commit: bc8bcac991aaa143015c099a0d804f23a21d0c48
Git-Repo: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
There is a demand[1] to support pid as well pidfd for process_madvise
to reduce unnecessary syscall to get pidfd if the user has control of
the target process (ie, they could guarantee the process is not gone or
pid is not reused).
This patch aims for supporting both options like waitid(2). So, the
syscall is currently,
int process_madvise(idtype_t idtype, id_t id, void *addr,
size_t length, int advice, unsigned long flags);
@which is actually idtype_t for userspace library and currently, it
supports P_PID and P_PIDFD.
[1] https://lore.kernel.org/linux-mm/9d849087-3359-c4ab-fbec-859e8186c509@virtuozzo.com/.
Change-Id: I06249a7621685e120e548a94098e6cce8d32d38d
Link: http://lkml.kernel.org/r/20200302193630.68771-6-minchan@kernel.org
Signed-off-by: Minchan Kim <minchan@kernel.org>
Suggested-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Reviewed-by: Suren Baghdasaryan <surenb@google.com>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Christian Brauner <christian@brauner.io>
Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Cc: Brian Geffon <bgeffon@google.com>
Cc: Daniel Colascione <dancol@google.com>
Cc: Jann Horn <jannh@google.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Joel Fernandes <joel@joelfernandes.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: John Dias <joaodias@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oleksandr Natalenko <oleksandr@redhat.com>
Cc: Sandeep Patil <sspatil@google.com>
Cc: SeongJae Park <sj38.park@gmail.com>
Cc: SeongJae Park <sjpark@amazon.de>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Sonny Rao <sonnyrao@google.com>
Cc: Tim Murray <timmurray@google.com>
Cc: Christian Brauner <christian.brauner@ubuntu.com>
Cc: <linux-man@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Git-Commit: 6c7663468de1b093e8ef5c0ef1df42c890f612bf
Git-Repo: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
There is usecase that System Management Software(SMS) want to give a
memory hint like MADV_[COLD|PAGEEOUT] to other processes and in the
case of Android, it is the ActivityManagerService.
The information required to make the reclaim decision is not known to
the app. Instead, it is known to the centralized userspace
daemon(ActivityManagerService), and that daemon must be able to
initiate reclaim on its own without any app involvement.
To solve the issue, this patch introduces a new syscall
process_madvise(2). It uses pidfd of an external process to give the
hint.
int process_madvise(int pidfd, void *addr, size_t length, int advice,
unsigned long flags);
Since it could affect other process's address range, only privileged
process(CAP_SYS_PTRACE) or something else(e.g., being the same UID)
gives it the right to ptrace the process could use it successfully.
The flag argument is reserved for future use if we need to extend the
API.
I think supporting all hints madvise has/will supported/support to
process_madvise is rather risky. Because we are not sure all hints
make sense from external process and implementation for the hint may
rely on the caller being in the current context so it could be
error-prone. Thus, I just limited hints as MADV_[COLD|PAGEOUT] in this
patch.
If someone want to add other hints, we could hear hear the usecase and
review it for each hint. It's safer for maintenance rather than
introducing a buggy syscall but hard to fix it later.
Q.1 - Why does any external entity have better knowledge?
Quote from Sandeep
"For Android, every application (including the special SystemServer)
are forked from Zygote. The reason of course is to share as many
libraries and classes between the two as possible to benefit from the
preloading during boot.
After applications start, (almost) all of the APIs end up calling into
this SystemServer process over IPC (binder) and back to the
application.
In a fully running system, the SystemServer monitors every single
process periodically to calculate their PSS / RSS and also decides
which process is "important" to the user for interactivity.
So, because of how these processes start _and_ the fact that the
SystemServer is looping to monitor each process, it does tend to *know*
which address range of the application is not used / useful.
Besides, we can never rely on applications to clean things up
themselves. We've had the "hey app1, the system is low on memory,
please trim your memory usage down" notifications for a long time[1].
They rely on applications honoring the broadcasts and very few do.
So, if we want to avoid the inevitable killing of the application and
restarting it, some way to be able to tell the OS about unimportant
memory in these applications will be useful.
- ssp
Q.2 - How to guarantee the race(i.e., object validation) between when
giving a hint from an external process and get the hint from the target
process?
process_madvise operates on the target process's address space as it
exists at the instant that process_madvise is called. If the space
target process can run between the time the process_madvise process
inspects the target process address space and the time that
process_madvise is actually called, process_madvise may operate on
memory regions that the calling process does not expect. It's the
responsibility of the process calling process_madvise to close this
race condition. For example, the calling process can suspend the
target process with ptrace, SIGSTOP, or the freezer cgroup so that it
doesn't have an opportunity to change its own address space before
process_madvise is called. Another option is to operate on memory
regions that the caller knows a priori will be unchanged in the target
process. Yet another option is to accept the race for certain
process_madvise calls after reasoning that mistargeting will do no
harm. The suggested API itself does not provide synchronization. It
also apply other APIs like move_pages, process_vm_write.
The race isn't really a problem though. Why is it so wrong to require
that callers do their own synchronization in some manner? Nobody
objects to write(2) merely because it's possible for two processes to
open the same file and clobber each other's writes --- instead, we tell
people to use flock or something. Think about mmap. It never
guarantees newly allocated address space is still valid when the user
tries to access it because other threads could unmap the memory right
before. That's where we need synchronization by using other API or
design from userside. It shouldn't be part of API itself. If someone
needs more fine-grained synchronization rather than process level,
there were two ideas suggested - cookie[2] and anon-fd[3]. Both are
applicable via using last reserved argument of the API but I don't
think it's necessary right now since we have already ways to prevent
the race so don't want to add additional complexity with more
fine-grained optimization model.
To make the API extend, it reserved an unsigned long as last argument
so we could support it in future if someone really needs it.
Q.3 - Why doesn't ptrace work?
Injecting an madvise in the target process using ptrace would not work
for us because such injected madvise would have to be executed by the
target process, which means that process would have to be runnable and
that creates the risk of the abovementioned race and hinting a wrong
VMA. Furthermore, we want to act the hint in caller's context, not the
callee's, because the callee is usually limited in cpuset/cgroups or
even freezed state so they can't act by themselves quick enough, which
causes more thrashing/kill. It doesn't work if the target process are
ptraced(e.g., strace, debugger, minidump) because a process can have at
most one ptracer.
[1] https://developer.android.com/topic/performance/memory"
[2] process_getinfo for getting the cookie which is updated whenever
vma of process address layout are changed - Daniel Colascione -
https://lore.kernel.org/lkml/20190520035254.57579-1-minchan@kernel.org/T/#m7694416fd179b2066a2c62b5b139b14e3894e224
[3] anonymous fd which is used for the object(i.e., address range)
validation - Michal Hocko -
https://lore.kernel.org/lkml/20200120112722.GY18451@dhcp22.suse.cz/
Conflicts:
arch/alpha/kernel/syscalls/syscall.tbl
arch/arm/tools/syscall.tbl
arch/arm64/include/asm/unistd.h
arch/arm64/include/asm/unistd32.h
arch/ia64/kernel/syscalls/syscall.tbl
arch/m68k/kernel/syscalls/syscall.tbl
arch/microblaze/kernel/syscalls/syscall.tbl
arch/mips/kernel/syscalls/syscall_n32.tbl
arch/mips/kernel/syscalls/syscall_n64.tbl
arch/parisc/kernel/syscalls/syscall.tbl
arch/powerpc/kernel/syscalls/syscall.tbl
arch/s390/kernel/syscalls/syscall.tbl
arch/sh/kernel/syscalls/syscall.tbl
arch/sparc/kernel/syscalls/syscall.tbl
arch/x86/entry/syscalls/syscall_32.tbl
arch/x86/entry/syscalls/syscall_64.tbl
arch/xtensa/kernel/syscalls/syscall.tbl
include/uapi/asm-generic/unistd.h
Link: http://lkml.kernel.org/r/20200302193630.68771-3-minchan@kernel.org
Link: http://lkml.kernel.org/r/20200508183320.GA125527@google.com
Signed-off-by: Minchan Kim <minchan@kernel.org>
Reviewed-by: Suren Baghdasaryan <surenb@google.com>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Cc: Brian Geffon <bgeffon@google.com>
Cc: Christian Brauner <christian@brauner.io>
Cc: Daniel Colascione <dancol@google.com>
Cc: Jann Horn <jannh@google.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Joel Fernandes <joel@joelfernandes.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: John Dias <joaodias@google.com>
Cc: Kirill Tkhai <ktkhai@virtuozzo.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oleksandr Natalenko <oleksandr@redhat.com>
Cc: Sandeep Patil <sspatil@google.com>
Cc: SeongJae Park <sj38.park@gmail.com>
Cc: SeongJae Park <sjpark@amazon.de>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Sonny Rao <sonnyrao@google.com>
Cc: Tim Murray <timmurray@google.com>
Cc: Christian Brauner <christian.brauner@ubuntu.com>
Cc: <linux-man@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Git-commit: 8422ccd91057d2814466d90ed05d44b359e88ba9
Git-Repo: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
[charante@codeaurora.org: Fixed merged conflicts]
Change-Id: I187d2a764db09f0868cd11c7536d7a1ed6a54f3a
Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
Certain GPIOs are reserved for secure world and cannot be accessed by HLOS.
Supply "reserved_gpios" to msm_pinctrl to mark these pins as invalid.
Change-Id: Ic8f45181b2210a6295bba1bdec45d24e607bede9
Signed-off-by: Mukesh Ojha <mojha@codeaurora.org>
Userspace does not have access to MM_STAT configs, so remove redundant
config checks.
Change-Id: I0ec0807a1e62bd5932f01ed285f2175f27900e37
Signed-off-by: Prakash Gupta <guptap@codeaurora.org>
Update pinctrl configuration for Shima, to match the
latest released configuration.
Change-Id: I1537735755e1a0384a9c48dca6184a85b49b2237
Signed-off-by: Mukesh Ojha <mojha@codeaurora.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl7qK2gACgkQONu9yGCS
aT4kaw/8Cknc9G64S1SWchxFj4LnSYzrpeFGXOZBlHBtcCyD12JNGjA6SG6DoGLY
/s/1fjBwJWrWpkI36CGNZowNPYtzRMOhyBGj7QHTpEj0vjMTKYXhVieMquQSHwRP
zcrYl8f/xWJKo6XNjR1YLh5PWeD6B9dWD1RcvBZ0jCez84jyVT1EyWMWGiodkLMx
gmJITO2DBaekelU0yyZJIFePO5DJpcXspf5lrPgkPG9u/U4hZf94AAGMYbXJZ5Rn
BDcqGEGQe+mtcG6lq6DGRDH5VVMG4k13MrZJBfrVAhkGU+g6nKQbOXCcdcRjoM6N
9NL8RbcpL0NhphNmrKwjNcYd4kZxYgTQb87FZi+qDxwGQIWIxcET6gL5t/vqAev1
v/uKFLlt5x/2tNtpC8aY8EwdyGcXfeBXEl9AjP7HUWC/KzB8I9vLnokcMvOMYDIg
3wNIsKMYLcLzuLL8oJ7FvDkBO+H/RjSvF4UvQyLOPOJtWSV5uKbLfKIU9sw90G3i
t8qo3lNC/J4saJ+jx+O7XoHjFw6biJFATvs0+HtpCkwi0aJm2SGW+OvXuZCGZPnz
TW2YsGFCCwL/RPtceJVkGfV3kr7SUB5AGXjueXdC+4QWfmi3POWojjgheQrleS+3
OLxRsUVbQ6hOqEgLAaV6HhzvykkTjDj2Gq8P3I+1Y/eiRHjlpdU=
=WYnW
-----END PGP SIGNATURE-----
Merge 5.4.47 into android-5.4-stable
Changes in 5.4.47
ipv6: fix IPV6_ADDRFORM operation logic
mlxsw: core: Use different get_trend() callbacks for different thermal zones
net_failover: fixed rollback in net_failover_open()
tun: correct header offsets in napi frags mode
bridge: Avoid infinite loop when suppressing NS messages with invalid options
vxlan: Avoid infinite loop when suppressing NS messages with invalid options
bpf: Support llvm-objcopy for vmlinux BTF
elfnote: mark all .note sections SHF_ALLOC
Input: mms114 - fix handling of mms345l
ARM: 8977/1: ptrace: Fix mask for thumb breakpoint hook
sched/fair: Don't NUMA balance for kthreads
Input: synaptics - add a second working PNP_ID for Lenovo T470s
csky: Fixup abiv2 syscall_trace break a4 & a5
gfs2: Even more gfs2_find_jhead fixes
drivers/net/ibmvnic: Update VNIC protocol version reporting
powerpc/xive: Clear the page tables for the ESB IO mapping
spi: dw: Fix native CS being unset
ath9k_htc: Silence undersized packet warnings
smack: avoid unused 'sip' variable warning
RDMA/uverbs: Make the event_queue fds return POLLERR when disassociated
padata: add separate cpuhp node for CPUHP_PADATA_DEAD
s390/pci: Log new handle in clp_disable_fh()
x86/cpu/amd: Make erratum #1054 a legacy erratum
KVM: x86: only do L1TF workaround on affected processors
PCI/PM: Adjust pcie_wait_for_link_delay() for caller delay
perf probe: Accept the instance number of kretprobe event
mm: add kvfree_sensitive() for freeing sensitive data objects
selftests: fix flower parent qdisc
fanotify: fix ignore mask logic for events on child and on dir
aio: fix async fsync creds
ipv4: fix a RCU-list lock in fib_triestat_seq_show
iwlwifi: mvm: fix NVM check for 3168 devices
sctp: fix possibly using a bad saddr with a given dst
sctp: fix refcount bug in sctp_wfree
x86_64: Fix jiffies ODR violation
x86/PCI: Mark Intel C620 MROMs as having non-compliant BARs
x86/speculation: Prevent rogue cross-process SSBD shutdown
x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.
x86/speculation: PR_SPEC_FORCE_DISABLE enforcement for indirect branches.
x86/reboot/quirks: Add MacBook6,1 reboot quirk
perf/x86/intel: Add more available bits for OFFCORE_RESPONSE of Intel Tremont
KVM: x86/mmu: Set mmio_value to '0' if reserved #PF can't be generated
KVM: x86: respect singlestep when emulating instruction
KVM: x86: Fix APIC page invalidation race
powerpc/ptdump: Properly handle non standard page size
ASoC: max9867: fix volume controls
io_uring: use kvfree() in io_sqe_buffer_register()
efi/efivars: Add missing kobject_put() in sysfs entry creation error path
smb3: fix incorrect number of credits when ioctl MaxOutputResponse > 64K
smb3: add indatalen that can be a non-zero value to calculation of credit charge in smb2 ioctl
watchdog: imx_sc_wdt: Fix reboot on crash
ALSA: es1688: Add the missed snd_card_free()
ALSA: fireface: fix configuration error for nominal sampling transfer frequency
ALSA: hda/realtek - add a pintbl quirk for several Lenovo machines
ALSA: pcm: disallow linking stream to itself
ALSA: pcm: fix snd_pcm_link() lockdep splat
ALSA: usb-audio: Fix inconsistent card PM state after resume
ALSA: usb-audio: Add vendor, product and profile name for HP Thunderbolt Dock
ACPI: sysfs: Fix reference count leak in acpi_sysfs_add_hotplug_profile()
ACPI: CPPC: Fix reference count leak in acpi_cppc_processor_probe()
ACPI: GED: add support for _Exx / _Lxx handler methods
ACPI: PM: Avoid using power resources if there are none for D0
arm64: acpi: fix UBSAN warning
lib/lzo: fix ambiguous encoding bug in lzo-rle
nilfs2: fix null pointer dereference at nilfs_segctor_do_construct()
spi: dw: Fix controller unregister order
spi: Fix controller unregister order
spi: pxa2xx: Fix controller unregister order
spi: pxa2xx: Fix runtime PM ref imbalance on probe error
spi: bcm2835: Fix controller unregister order
spi: bcm2835aux: Fix controller unregister order
spi: bcm-qspi: Handle clock probe deferral
spi: bcm-qspi: when tx/rx buffer is NULL set to 0
PM: runtime: clk: Fix clk_pm_runtime_get() error path
gup: document and work around "COW can break either way" issue
crypto: cavium/nitrox - Fix 'nitrox_get_first_device()' when ndevlist is fully iterated
crypto: algapi - Avoid spurious modprobe on LOADED
crypto: drbg - fix error return code in drbg_alloc_state()
x86/{mce,mm}: Unmap the entire page if the whole page is affected and poisoned
firmware: imx: warn on unexpected RX
firmware: imx-scu: Support one TX and one RX
firmware: imx: scu: Fix corruption of header
crypto: virtio: Fix use-after-free in virtio_crypto_skcipher_finalize_req()
crypto: virtio: Fix src/dst scatterlist calculation in __virtio_crypto_skcipher_do_req()
crypto: virtio: Fix dest length calculation in __virtio_crypto_skcipher_do_req()
dccp: Fix possible memleak in dccp_init and dccp_fini
selftests/net: in rxtimestamp getopt_long needs terminating null entry
net/mlx5: drain health workqueue in case of driver load error
net/mlx5: Fix fatal error handling during device load
net/mlx5e: Fix repeated XSK usage on one channel
ovl: initialize error in ovl_copy_xattr
proc: Use new_inode not new_inode_pseudo
remoteproc: Fall back to using parent memory pool if no dedicated available
remoteproc: Fix and restore the parenting hierarchy for vdev
cpufreq: Fix up cpufreq_boost_set_sw()
EDAC/skx: Use the mcmtr register to retrieve close_pg/bank_xor_enable
video: vt8500lcdfb: fix fallthrough warning
video: fbdev: w100fb: Fix a potential double free.
KVM: nVMX: Skip IBPB when switching between vmcs01 and vmcs02
KVM: nSVM: fix condition for filtering async PF
KVM: nSVM: leave ASID aside in copy_vmcb_control_area
KVM: nVMX: Consult only the "basic" exit reason when routing nested exit
KVM: MIPS: Define KVM_ENTRYHI_ASID to cpu_asid_mask(&boot_cpu_data)
KVM: MIPS: Fix VPN2_MASK definition for variable cpu_vmbits
KVM: arm64: Stop writing aarch32's CSSELR into ACTLR
KVM: arm64: Make vcpu_cp1x() work on Big Endian hosts
scsi: megaraid_sas: TM command refire leads to controller firmware crash
scsi: lpfc: Fix negation of else clause in lpfc_prep_node_fc4type
selftests/ftrace: Return unsupported if no error_log file
ath9k: Fix use-after-free Read in htc_connect_service
ath9k: Fix use-after-free Read in ath9k_wmi_ctrl_rx
ath9k: Fix use-after-free Write in ath9k_htc_rx_msg
ath9x: Fix stack-out-of-bounds Write in ath9k_hif_usb_rx_cb
ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb
Smack: slab-out-of-bounds in vsscanf
drm/vkms: Hold gem object while still in-use
mm/slub: fix a memory leak in sysfs_slab_add()
fat: don't allow to mount if the FAT length == 0
perf: Add cond_resched() to task_function_call()
agp/intel: Reinforce the barrier after GTT updates
mmc: sdhci-msm: Clear tuning done flag while hs400 tuning
mmc: mmci_sdmmc: fix DMA API warning overlapping mappings
mmc: tmio: Further fixup runtime PM management at remove
mmc: uniphier-sd: call devm_request_irq() after tmio_mmc_host_probe()
ARM: dts: at91: sama5d2_ptc_ek: fix sdmmc0 node description
mmc: sdio: Fix potential NULL pointer error in mmc_sdio_init_card()
mmc: sdio: Fix several potential memory leaks in mmc_sdio_init_card()
block/floppy: fix contended case in floppy_queue_rq()
xen/pvcalls-back: test for errors when calling backend_connect()
KVM: arm64: Synchronize sysreg state on injecting an AArch32 exception
KVM: arm64: Save the host's PtrAuth keys in non-preemptible context
Linux 5.4.47
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I3fb3216abdbc080b4ac7b827b35ff6a813e28eb8
There is a possibility of client driver's dev_wake request
as part mhi_device_get() racing with M1 state transition
event processing. This can result in a scenario where client
finds MHI state as M0 after mhi_device_get() returns only to
be changed later as M1 event processing is still pending on
different CPU core.
It causes M0 -> M2 -> M0 state transition after mhi_device_get()
has already returned. This isn't expected by client and currently
treats that as fatal error. Also, as per MHI spec host must allow
M1 -> M2 transition for device and it shouldn't abort that.
However, clients can ignore that transition as device is expected
to immediately move from M2 to M0 without entering deep sleep
state. Hence, it must be safe to access their MMIO.
To simplify this logic, introduce mhi_device_get_sync_atomic()
function that can be used by clients to achieve the same and once
it returns success they don't need to have any explicit MHI state
checks.
Change-Id: I0b4a1ad723a0444ee2402bf171fc5ffc46afcdce
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
Record the status and timestamp of the last interrupt and print them along
with host states, which is helpful for debugging purposes.
Change-Id: I2f9946b07ec64fb68516e905f19800c71964536e
Signed-off-by: Can Guo <cang@codeaurora.org>
The scsi_block_reqs_cnt increased in ufshcd_hold() is supposed to be
decreased back in ufshcd_ungate_work() in a paired way. However, if
specific ufshcd_hold/release sequences are met, it is possible that
scsi_block_reqs_cnt is increased twice but only one ungate work is
queued. To make sure scsi_block_reqs_cnt is handled by ufshcd_hold() and
ufshcd_ungate_work() in a paired way, increase it only if queue_work()
returns true.
Change-Id: Ibe8e77dc2c6317d10a593ec270a942cb7bcd4f4c
Signed-off-by: Can Guo <cang@codeaurora.org>
Make sure key size is what is expected by command packet
for KEY_UNWRAP_IMPORT in order to not overflow the buffer
and corrupt the stack.
Change-Id: Iba1d6bb3bf5efc4f4e64dafce0fbb65bb6f7b8c6
Signed-off-by: Gaurav Kashyap <gaurkash@codeaurora.org>
