Let's count the number of CMA pages per zone and print them in
/proc/zoneinfo.
Having access to the total number of CMA pages per zone is helpful for
debugging purposes to know where exactly the CMA pages ended up, and to
figure out how many pages of a zone might behave differently, even after
some of these pages might already have been allocated.
As one example, CMA pages part of a kernel zone cannot be used for
ordinary kernel allocations but instead behave more like ZONE_MOVABLE.
For now, we are only able to get the global nr+free cma pages from
/proc/meminfo and the free cma pages per zone from /proc/zoneinfo.
Example after this patch when booting a 6 GiB QEMU VM with
"hugetlb_cma=2G":
# cat /proc/zoneinfo | grep cma
cma 0
nr_free_cma 0
cma 0
nr_free_cma 0
cma 524288
nr_free_cma 493016
cma 0
cma 0
# cat /proc/meminfo | grep Cma
CmaTotal: 2097152 kB
CmaFree: 1972064 kB
Note: We print even without CONFIG_CMA, just like "nr_free_cma"; this way,
one can be sure when spotting "cma 0", that there are definetly no
CMA pages located in a zone.
[david@redhat.com: v2]
Link: https://lkml.kernel.org/r/20210128164533.18566-1-david@redhat.com
[david@redhat.com: v3]
Link: https://lkml.kernel.org/r/20210129113451.22085-1-david@redhat.com
Link: https://lkml.kernel.org/r/20210127101813.6370-3-david@redhat.com
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Acked-by: David Rientjes <rientjes@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Wei Yang <richard.weiyang@linux.alibaba.com>
Cc: Zi Yan <ziy@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 3c381db1fa)
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: Ia4496355853c7bb7201f09394369cd42f632c079
Right now, if activation fails, we might already have exposed some pages
to the buddy for CMA use (although they will never get actually used by
CMA), and some pages won't be exposed to the buddy at all.
Let's check for "single zone" early and on error, don't expose any pages
for CMA use - instead, expose them to the buddy available for any use.
Simply call free_reserved_page() on every single page - easier than going
via free_reserved_area(), converting back and forth between pfns and virt
addresses.
In addition, make sure to fixup totalcma_pages properly.
Example: 6 GiB QEMU VM with "... hugetlb_cma=2G movablecore=20% ...":
[ 0.006891] hugetlb_cma: reserve 2048 MiB, up to 2048 MiB per node
[ 0.006893] cma: Reserved 2048 MiB at 0x0000000100000000
[ 0.006893] hugetlb_cma: reserved 2048 MiB on node 0
...
[ 0.175433] cma: CMA area hugetlb0 could not be activated
Before this patch:
# cat /proc/meminfo
MemTotal: 5867348 kB
MemFree: 5692808 kB
MemAvailable: 5542516 kB
...
CmaTotal: 2097152 kB
CmaFree: 1884160 kB
After this patch:
# cat /proc/meminfo
MemTotal: 6077308 kB
MemFree: 5904208 kB
MemAvailable: 5747968 kB
...
CmaTotal: 0 kB
CmaFree: 0 kB
Note: cma_init_reserved_mem() makes sure that we always cover full
pageblocks / MAX_ORDER - 1 pages.
Link: https://lkml.kernel.org/r/20210127101813.6370-2-david@redhat.com
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Zi Yan <ziy@nvidia.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Wei Yang <richard.weiyang@linux.alibaba.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 072355c1cf)
Signed-off-by: Minchan Kim <minchan@google.com>
Bug: 181887812
Change-Id: Ia8b6e3b0dfef59fe36693db0d235fb75cce9e61e
Currently cma areas without a fixed base are allocated close to the end of
the node. This placement is sub-optimal because of compaction: it brings
pages into the cma area. In particular, it can bring in hot executable
pages, even if there is a plenty of free memory on the machine. This
results in cma allocation failures.
Instead let's place cma areas close to the beginning of a node. In this
case the compaction will help to free cma areas, resulting in better cma
allocation success rates.
If there is enough memory let's try to allocate bottom-up starting with
4GB to exclude any possible interference with DMA32. On smaller machines
or in a case of a failure, stick with the old behavior.
16GB vm, 2GB cma area:
With this patch:
[ 0.000000] Command line: root=/dev/vda3 rootflags=subvol=/root systemd.unified_cgroup_hierarchy=1 enforcing=0 console=ttyS0,115200 hugetlb_cma=2G
[ 0.002928] hugetlb_cma: reserve 2048 MiB, up to 2048 MiB per node
[ 0.002930] cma: Reserved 2048 MiB at 0x0000000100000000
[ 0.002931] hugetlb_cma: reserved 2048 MiB on node 0
Without this patch:
[ 0.000000] Command line: root=/dev/vda3 rootflags=subvol=/root systemd.unified_cgroup_hierarchy=1 enforcing=0 console=ttyS0,115200 hugetlb_cma=2G
[ 0.002930] hugetlb_cma: reserve 2048 MiB, up to 2048 MiB per node
[ 0.002933] cma: Reserved 2048 MiB at 0x00000003c0000000
[ 0.002934] hugetlb_cma: reserved 2048 MiB on node 0
v2:
- switched to memblock_set_bottom_up(true), by Mike
- start with 4GB, by Mike
[guro@fb.com: whitespace fix, per Mike]
Link: https://lkml.kernel.org/r/20201221170551.GB3428478@carbon.DHCP.thefacebook.com
[guro@fb.com: fix 32-bit warnings]
Link: https://lkml.kernel.org/r/20201223163537.GA4011967@carbon.DHCP.thefacebook.com
[guro@fb.com: fix 32-bit systems]
[akpm@linux-foundation.org: build fix]
Link: https://lkml.kernel.org/r/20201217201214.3414100-1-guro@fb.com
Signed-off-by: Roman Gushchin <guro@fb.com>
Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
Cc: Wonhyuk Yang <vvghjk1234@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Rik van Riel <riel@surriel.com>
Cc: Michal Hocko <mhocko@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit df2ff39e78)
Signed-off-by: Minchan Kim <minchan@google.com>
Bug: 181887812
Change-Id: If1e983f09b84f4482f45cc9c27454952893257cb
It is required to print 'count' of pages, along with the pages, passed to
cma_release to debug the cases of mismatched count value passed between
cma_alloc() and cma_release() from a code path.
As an example, consider the below scenario:
1) CMA pool size is 4MB and
2) User doing the erroneous step of allocating 2 pages but freeing 1
page in a loop from this CMA pool. The step 2 causes cma_alloc() to
return NULL at one point of time because of -ENOMEM condition.
And the current pr_debug logs is not giving the info about these types of
allocation patterns because of count value not being printed in
cma_release().
We are printing the count value in the trace logs, just extend the same to
pr_debug logs too.
[akpm@linux-foundation.org: fix printk warning]
Link: https://lkml.kernel.org/r/1606318341-29521-1-git-send-email-charante@codeaurora.org
Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
Reviewed-by: Souptick Joarder <jrdr.linux@gmail.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Vinayak Menon <vinmenon@codeaurora.org>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit b8ca396f98)
Signed-off-by: Minchan Kim <minchan@google.com>
Bug: 181887812
Change-Id: I54ab577c1509e663207cc4e33e2ac737ea254fd2
The cma_mutex which protects alloc_contig_range() was first appeared in
commit 7ee793a62f ("cma: Remove potential deadlock situation"), at that
time, there is no guarantee the behavior of concurrency inside
alloc_contig_range().
After commit 2c7452a075 ("mm/page_isolation.c: make
start_isolate_page_range() fail if already isolated")
> However, two subsystems (CMA and gigantic
> huge pages for example) could attempt operations on the same range. If
> this happens, one thread may 'undo' the work another thread is doing.
> This can result in pageblocks being incorrectly left marked as
> MIGRATE_ISOLATE and therefore not available for page allocation.
The concurrency inside alloc_contig_range() was clarified.
Now we can find that hugepage and virtio call alloc_contig_range() without
any lock, thus cma_mutex is "redundant" in cma_alloc() now.
Link: https://lkml.kernel.org/r/20201020102241.3729-1-lecopzer.chen@mediatek.com
Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
Acked-by: David Hildenbrand <david@redhat.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: YJ Chiang <yj.chiang@mediatek.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit a4efc174b3)
minchan: Resolved minor conflict with alloc_contig_range in mm/cma.c ]
Bug: 181887812
Change-Id: I0138e571f8131ed1d53ee91b61a037bc762d824a
Like was done for the other non-upstream methods in
'struct ufs_hba_variant_ops', replace ->fill_prdt() with an Android
vendor hook. This is considered to be better because it avoids any
conflicts with upstream changes to 'struct ufs_hba_variant_ops'.
Note that as a side effect of this change, fill_prdt is no longer
allowed to sleep. That's fine for the only known use of this hook.
Bug: 162257402
Bug: 181359082
Change-Id: I8096932525c27b969193d769aff511a0114b35ad
Signed-off-by: Eric Biggers <ebiggers@google.com>
This is now provided through the prebuilt build-tools.
Bug: 179516498
Signed-off-by: Matthias Maennich <maennich@google.com>
Change-Id: I23152d35944b1efdb7aab9ef6c55aaad2ae1cbed
Add gfp_zone, __next_zones_zonelist, zone_watermark_ok_safe and
zone_watermark_ok for watermark checking. Add __refrigerator to make
use of the DMA-BUF Heap deferred free helper. Remove all ION symbols.
Bug: 181756083
Signed-off-by: Chris Goldsworthy <cgoldswo@codeaurora.org>
Change-Id: I7b08e4786576c0e964d80f3981c74b494f7a0abb
android_vh_do_wake_up_sync:
To modify the mode value of __wake_up_sync_key
android_vh_set_wake_flags:
To modify the wake flag from a module
Bug: 181743516
Signed-off-by: Namkyu Kim <namkyu78.kim@samsung.com>
Change-Id: I972e2469c3f139373d21f1e8c85974763388a693
Commit 8d420888a4 ("ANDROID: sched: Add PELT cmdline arg") removed the
'__maybe_unused' and 'const' qualifiers from the declaration of the PELT
arrays for no apparent reason.
Re-introduce both of them to silence the 'Maybe unused' warnings and
align as much as possible with upstream.
Bug: 177593580
Fixes: 8d420888a4 ("ANDROID: sched: Add PELT cmdline arg")
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: I5416726a285eff881ba7bc5188f8a69ee40b1f99
Add an overwrite to platform specific callback for setting up the
xhci_vendor_ops, allow vendor to store the xhci_vendor_ops and
overwrite them when xhci_plat_probe invoked.
This change is depend on Commit in this patch series
("usb: host: add xhci hooks for USB offload"), vendor needs
to invoke xhci_plat_register_vendor_ops() to register the vendor specific
vendor_ops. And the vendor_ops will overwrite the vendor_ops inside
xhci_plat_priv in xhci_vendor_init() during xhci-plat-hcd probe.
Signed-off-by: Howard Yen <howardyen@google.com>
Bug: 175358363
Link: https://lore.kernel.org/r/20210119101044.1637023-1-howardyen@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I57137d91c9b83df92ce633bff65ab72e48a9005d
Export symbols for xhci hooks usage:
xhci_ring_free
- Allow xhci hook to free xhci_ring.
xhci_get_slot_ctx
- Allow xhci hook to get slot_ctx from the xhci_container_ctx
for getting the slot_ctx information to know which slot is
offloading and compare the context in remote subsystem memory
if needed.
xhci_get_ep_ctx
- Allow xhci hook to get ep_ctx from the xhci_container_ctx for
getting the ep_ctx information to know which ep is offloading and
comparing the context in remote subsystem memory if needed.
xhci_handle_event
- Allow xhci hook to handle the xhci events from the USB
controller.
xhci_update_erst_dequeue
- If xhci events was handle by xhci hook, it needs to update
the erst dequeue pointer to let the USB controller know the
events was handled.
Signed-off-by: Howard Yen <howardyen@google.com>
Bug: 175358363
Link: https://lore.kernel.org/r/20210119101044.1637023-1-howardyen@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ic7511048c009a2ff5f2832eee971140216105f6e
To enable supporting for USB offload, define "offload" in usb controller
node of device tree. "offload" value can be used to determine which type
of offload was been enabled in the SoC.
For example:
&usbdrd_dwc3 {
...
/* support usb offloading, 0: disabled, 1: audio */
offload = <1>;
...
};
There are several vendor_ops introduced by this patch:
struct xhci_vendor_ops - function callbacks for vendor specific operations
{
@vendor_init:
- called for vendor init process during xhci-plat-hcd
probe.
@vendor_cleanup:
- called for vendor cleanup process during xhci-plat-hcd
remove.
@is_usb_offload_enabled:
- called to check if usb offload enabled.
@queue_irq_work:
- called to queue vendor specific irq work.
@alloc_dcbaa:
- called when allocating vendor specific dcbaa during
memory initializtion.
@free_dcbaa:
- called to free vendor specific dcbaa when cleanup the
memory.
@alloc_transfer_ring:
- called when vendor specific transfer ring allocation is required
@free_transfer_ring:
- called to free vendor specific transfer ring
@sync_dev_ctx:
- called when synchronization for device context is required
}
The xhci hooks with prefix "xhci_vendor_" on the ops in xhci_vendor_ops.
For example, vendor_init ops will be invoked by xhci_vendor_init() hook,
is_usb_offload_enabled ops will be invoked by
xhci_vendor_is_usb_offload_enabled(), and so on.
Signed-off-by: Howard Yen <howardyen@google.com>
Bug: 175358363
Link: https://lore.kernel.org/r/20210119101044.1637023-1-howardyen@google.com
Signed-off-by: Greg Kroah-Harktman <gregkh@google.com>
Change-Id: Ia31ab4308264d0549bb8b7cf65dfa401a987110e
Kbuild composite objects only supports one level of composite objects.
That is, a composite object may only be composed of real compilable
source files.
As a simple example, the following Kbuild description is now supported:
bar-a-y := a/bar0.o a/bar1.o
bar-b-y := b/bar2.o b/bar3.o
foo-objs := bar-a.o bar-b.o
obj-m += foo.o
Add such support by recursively searching for composite objects and
listing them in $(multi-used-*) and $(real-obj-*).
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
Bug: 175420575
Change-Id: I08880422bc462c38b80f1a8bd85498250898c85e
Link: https://lore.kernel.org/linux-kbuild/1611343638-28206-3-git-send-email-eberman@codeaurora.org/
[eberman@codeaurora.org: Fix compile error so that multi-search does not
recurse when foo-y contains foo.o]
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
This reverts commit 631b20dd6c ("ANDROID: kbuild: simplify cmd_mod")
since this causes regression in how Kbuild handles dependencies.
Bug: 175420575
Change-Id: I162eedf19357287c5ab9840ed84081d071aa320b
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
This reverts commit f50aeaf27c ("ANDROID: kbuild: handle excessively
long argument lists") since it causes regression in how kbuild handles
dependencies.
Bug: 175420575
Change-Id: I5ed5e883e7b0886dee8491dd888aa82d42452e79
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
Commit e7e832ce6f ("fs: add LSM-supporting anon-inode interface") adds
more kerneldoc description, but also a few new warnings on
anon_inode_getfd_secure() due to missing parameter descriptions.
Rephrase to appropriate kernel-doc for anon_inode_getfd_secure().
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
(cherry picked from commit 365982aba1)
Bug: 160737021
Bug: 169683130
Signed-off-by: Lokesh Gidra <lokeshgidra@google.com>
Change-Id: I7b8882d9da9ac37bc285dfb753bbe9ddf1f9fd04
Having added the support for SCMI protocols as modules in order to let
vendors extend the SCMI core with their own additions it seems odd to
then force SCMI drivers built on top to use a static device table to
declare their devices since this way any new SCMI drivers addition
would need the core SCMI device table to be updated too.
Remove the static core device table and let SCMI drivers to simply declare
which device/protocol pair they need at initialization time: the core will
then take care to generate such devices dynamically during platform
initialization or at module loading time, as long as the requested
underlying protocol is defined in the DT.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Bug: 171409184
Link: https://lore.kernel.org/linux-arm-kernel/20210202221555.41167-1-cristian.marussi@arm.com/
Change-Id: Ibe69c2f6169b078ad274d06000dbdcf0aee42901
Signed-off-by: Rishabh Bhatnagar <quic_rishabhb@quicinc.com>
Notification private data is currently accessible via handle->notify_priv;
this data was indeed meant to be private to the notification core support
and not to be accessible by SCMI drivers: make it private hiding it inside
instance descriptor struct scmi_info and accessible only via dedicated
helpers.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Bug: 171409184
Link: https://lore.kernel.org/linux-arm-kernel/20210202221555.41167-1-cristian.marussi@arm.com/
Change-Id: Ic0a1c0610f9726f3ebde388e685ee20343533d33
Signed-off-by: Rishabh Bhatnagar <quic_rishabhb@quicinc.com>
Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations, while keeping the old handle->voltage_ops still
around to ease transition.
Remove handle->voltage_priv now unused.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Bug: 171409184
Link: https://lore.kernel.org/linux-arm-kernel/20210202221555.41167-1-cristian.marussi@arm.com/
Change-Id: I3a0c415891792c46bc94179f063068fe913efe5f
Signed-off-by: Rishabh Bhatnagar <quic_rishabhb@quicinc.com>
Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations, while keeping the old handle->sensor_ops still
around to ease transition.
Remove handle->sensor_priv now unused.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Bug: 171409184
Link: https://lore.kernel.org/linux-arm-kernel/20210202221555.41167-1-cristian.marussi@arm.com/
Change-Id: I5928b7dfa0828139c9c4edf81169ea875119ebc6
Signed-off-by: Rishabh Bhatnagar <quic_rishabhb@quicinc.com>
Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations, while keeping the old handle->reset_ops still
around to ease transition.
Remove handle->reset_priv now unused.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Bug: 171409184
Link: https://lore.kernel.org/linux-arm-kernel/20210202221555.41167-1-cristian.marussi@arm.com/
Change-Id: Iaf3ded6b344194dcfc4fcef5fc5cbadb6f8da07c
Signed-off-by: Rishabh Bhatnagar <quic_rishabhb@quicinc.com>
Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations, while keeping the old handle->clk_ops still
around to ease transition.
Remove handle->clock_priv now unused.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Bug: 171409184
Link: https://lore.kernel.org/linux-arm-kernel/20210202221555.41167-1-cristian.marussi@arm.com/
Change-Id: I57fffd97027470f96ffde4222ea997b67285207d
Signed-off-by: Rishabh Bhatnagar <quic_rishabhb@quicinc.com>
Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations, while keeping the old handle->power_ops still
around to ease transition.
Remove handle->power_priv now unused.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Bug: 171409184
Link: https://lore.kernel.org/linux-arm-kernel/20210202221555.41167-1-cristian.marussi@arm.com/
Change-Id: Iaaaa1094d8cff6eec7ea6a21cbf0be9dbaa6fb32
Signed-off-by: Rishabh Bhatnagar <quic_rishabhb@quicinc.com>
