From: Alexandru Elisei <alexandru.elisei@arm.com> To: Anshuman Khandual <anshuman.khandual@arm.com> Cc: catalin.marinas@arm.com, will@kernel.org, oliver.upton@linux.dev, maz@kernel.org, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, arnd@arndb.de, akpm@linux-foundation.org, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, vschneid@redhat.com, mhiramat@kernel.org, rppt@kernel.org, hughd@google.com, pcc@google.com, steven.price@arm.com, vincenzo.frascino@arm.com, david@redhat.com, eugenis@google.com, kcc@google.com, hyesoo.yu@samsung.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org Subject: Re: [PATCH RFC v3 08/35] mm: cma: Introduce cma_alloc_range() Date: Wed, 31 Jan 2024 14:18:22 +0000 [thread overview] Message-ID: <ZbpWripbKW5MaV8J@raptor> (raw) In-Reply-To: <d22f63a0-f6de-44e1-874b-24d707907858@arm.com> Hi, On Wed, Jan 31, 2024 at 11:54:17AM +0530, Anshuman Khandual wrote: > > > On 1/30/24 17:05, Alexandru Elisei wrote: > > Hi, > > > > On Tue, Jan 30, 2024 at 10:50:00AM +0530, Anshuman Khandual wrote: > >> > >> On 1/25/24 22:12, Alexandru Elisei wrote: > >>> Today, cma_alloc() is used to allocate a contiguous memory region. The > >>> function allows the caller to specify the number of pages to allocate, but > >>> not the starting address. cma_alloc() will walk over the entire CMA region > >>> trying to allocate the first available range of the specified size. > >>> > >>> Introduce cma_alloc_range(), which makes CMA more versatile by allowing the > >>> caller to specify a particular range in the CMA region, defined by the > >>> start pfn and the size. > >>> > >>> arm64 will make use of this function when tag storage management will be > >>> implemented: cma_alloc_range() will be used to reserve the tag storage > >>> associated with a tagged page. > >> Basically, you would like to pass on a preferred start address and the > >> allocation could just fail if a contig range is not available from such > >> a starting address ? > >> > >> Then why not just change cma_alloc() to take a new argument 'start_pfn'. > >> Why create a new but almost similar allocator ? > > I tried doing that, and I gave up because: > > > > - It made cma_alloc() even more complex and hard to follow. > > > > - What value should 'start_pfn' be to tell cma_alloc() that it should be > > ignored? Or, to put it another way, what pfn number is invalid on **all** > > platforms that Linux supports? > > > > I can give it another go if we can come up with an invalid value for > > 'start_pfn'. > > Something negative might work. How about -1/-1UL ? A quick search gives > some instances such as ... > > git grep "pfn == -1" > > mm/mm_init.c: if (*start_pfn == -1UL) > mm/vmscan.c: if (pfn == -1) > mm/vmscan.c: if (pfn == -1) > mm/vmscan.c: if (pfn == -1) > tools/testing/selftests/mm/hugepage-vmemmap.c: if (pfn == -1UL) { > > Could not -1UL be abstracted as common macro MM_INVALID_PFN to be used in > such scenarios including here ? Ah yes, you are right, get_pte_pfn() already uses -1 as an invalid pfn, so I can just use that. Will definitely give it a go on the next iteration, thanks for the suggestion! > > > > >> But then I am wondering why this could not be done in the arm64 platform > >> code itself operating on a CMA area reserved just for tag storage. Unless > >> this new allocator has other usage beyond MTE, this could be implemented > >> in the platform itself. > > I had the same idea in the previous iteration, David Hildenbrand suggested > > this approach [1]. > > > > [1] https://lore.kernel.org/linux-fsdevel/2aafd53f-af1f-45f3-a08c-d11962254315@redhat.com/ > > There are two different cma_alloc() proposals here - including the next > patch i.e mm: cma: Fast track allocating memory when the pages are free > > 1) Augment cma_alloc() or add cma_alloc_range() with start_pfn parameter > 2) Speed up cma_alloc() for small allocation requests when pages are free > > The second one if separated out from this series could be considered on > its own as it will help all existing cma_alloc() callers. The first one > definitely needs an use case as provided in this series. I understand, thanks for the input! Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alexandru Elisei <alexandru.elisei@arm.com> To: Anshuman Khandual <anshuman.khandual@arm.com> Cc: catalin.marinas@arm.com, will@kernel.org, oliver.upton@linux.dev, maz@kernel.org, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, arnd@arndb.de, akpm@linux-foundation.org, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, vschneid@redhat.com, mhiramat@kernel.org, rppt@kernel.org, hughd@google.com, pcc@google.com, steven.price@arm.com, vincenzo.frascino@arm.com, david@redhat.com, eugenis@google.com, kcc@google.com, hyesoo.yu@samsung.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org Subject: Re: [PATCH RFC v3 08/35] mm: cma: Introduce cma_alloc_range() Date: Wed, 31 Jan 2024 14:18:22 +0000 [thread overview] Message-ID: <ZbpWripbKW5MaV8J@raptor> (raw) In-Reply-To: <d22f63a0-f6de-44e1-874b-24d707907858@arm.com> Hi, On Wed, Jan 31, 2024 at 11:54:17AM +0530, Anshuman Khandual wrote: > > > On 1/30/24 17:05, Alexandru Elisei wrote: > > Hi, > > > > On Tue, Jan 30, 2024 at 10:50:00AM +0530, Anshuman Khandual wrote: > >> > >> On 1/25/24 22:12, Alexandru Elisei wrote: > >>> Today, cma_alloc() is used to allocate a contiguous memory region. The > >>> function allows the caller to specify the number of pages to allocate, but > >>> not the starting address. cma_alloc() will walk over the entire CMA region > >>> trying to allocate the first available range of the specified size. > >>> > >>> Introduce cma_alloc_range(), which makes CMA more versatile by allowing the > >>> caller to specify a particular range in the CMA region, defined by the > >>> start pfn and the size. > >>> > >>> arm64 will make use of this function when tag storage management will be > >>> implemented: cma_alloc_range() will be used to reserve the tag storage > >>> associated with a tagged page. > >> Basically, you would like to pass on a preferred start address and the > >> allocation could just fail if a contig range is not available from such > >> a starting address ? > >> > >> Then why not just change cma_alloc() to take a new argument 'start_pfn'. > >> Why create a new but almost similar allocator ? > > I tried doing that, and I gave up because: > > > > - It made cma_alloc() even more complex and hard to follow. > > > > - What value should 'start_pfn' be to tell cma_alloc() that it should be > > ignored? Or, to put it another way, what pfn number is invalid on **all** > > platforms that Linux supports? > > > > I can give it another go if we can come up with an invalid value for > > 'start_pfn'. > > Something negative might work. How about -1/-1UL ? A quick search gives > some instances such as ... > > git grep "pfn == -1" > > mm/mm_init.c: if (*start_pfn == -1UL) > mm/vmscan.c: if (pfn == -1) > mm/vmscan.c: if (pfn == -1) > mm/vmscan.c: if (pfn == -1) > tools/testing/selftests/mm/hugepage-vmemmap.c: if (pfn == -1UL) { > > Could not -1UL be abstracted as common macro MM_INVALID_PFN to be used in > such scenarios including here ? Ah yes, you are right, get_pte_pfn() already uses -1 as an invalid pfn, so I can just use that. Will definitely give it a go on the next iteration, thanks for the suggestion! > > > > >> But then I am wondering why this could not be done in the arm64 platform > >> code itself operating on a CMA area reserved just for tag storage. Unless > >> this new allocator has other usage beyond MTE, this could be implemented > >> in the platform itself. > > I had the same idea in the previous iteration, David Hildenbrand suggested > > this approach [1]. > > > > [1] https://lore.kernel.org/linux-fsdevel/2aafd53f-af1f-45f3-a08c-d11962254315@redhat.com/ > > There are two different cma_alloc() proposals here - including the next > patch i.e mm: cma: Fast track allocating memory when the pages are free > > 1) Augment cma_alloc() or add cma_alloc_range() with start_pfn parameter > 2) Speed up cma_alloc() for small allocation requests when pages are free > > The second one if separated out from this series could be considered on > its own as it will help all existing cma_alloc() callers. The first one > definitely needs an use case as provided in this series. I understand, thanks for the input! Alex _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-01-31 14:18 UTC|newest] Thread overview: 190+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-01-25 16:42 [PATCH RFC v3 00/35] Add support for arm64 MTE dynamic tag storage reuse Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 01/35] mm: page_alloc: Add gfp_flags parameter to arch_alloc_page() Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-29 5:48 ` Anshuman Khandual 2024-01-29 5:48 ` Anshuman Khandual 2024-01-29 11:41 ` Alexandru Elisei 2024-01-29 11:41 ` Alexandru Elisei 2024-01-30 4:26 ` Anshuman Khandual 2024-01-30 4:26 ` Anshuman Khandual 2024-01-30 11:56 ` Alexandru Elisei 2024-01-30 11:56 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 02/35] mm: page_alloc: Add an arch hook early in free_pages_prepare() Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-29 8:19 ` Anshuman Khandual 2024-01-29 8:19 ` Anshuman Khandual 2024-01-29 11:42 ` Alexandru Elisei 2024-01-29 11:42 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 03/35] mm: page_alloc: Add an arch hook to filter MIGRATE_CMA allocations Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-29 8:44 ` Anshuman Khandual 2024-01-29 8:44 ` Anshuman Khandual 2024-01-29 11:45 ` Alexandru Elisei 2024-01-29 11:45 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 04/35] mm: page_alloc: Partially revert "mm: page_alloc: remove stale CMA guard code" Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-29 9:01 ` Anshuman Khandual 2024-01-29 9:01 ` Anshuman Khandual 2024-01-29 11:46 ` Alexandru Elisei 2024-01-29 11:46 ` Alexandru Elisei 2024-01-30 4:34 ` Anshuman Khandual 2024-01-30 4:34 ` Anshuman Khandual 2024-01-30 11:57 ` Alexandru Elisei 2024-01-30 11:57 ` Alexandru Elisei 2024-01-31 3:27 ` Anshuman Khandual 2024-01-31 3:27 ` Anshuman Khandual 2024-01-25 16:42 ` [PATCH RFC v3 05/35] mm: cma: Don't append newline when generating CMA area name Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-29 9:13 ` Anshuman Khandual 2024-01-29 9:13 ` Anshuman Khandual 2024-01-29 11:46 ` Alexandru Elisei 2024-01-29 11:46 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 06/35] mm: cma: Make CMA_ALLOC_SUCCESS/FAIL count the number of pages Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-29 9:24 ` Anshuman Khandual 2024-01-29 9:24 ` Anshuman Khandual 2024-01-29 11:51 ` Alexandru Elisei 2024-01-29 11:51 ` Alexandru Elisei 2024-01-30 4:52 ` Anshuman Khandual 2024-01-30 4:52 ` Anshuman Khandual 2024-01-30 11:58 ` Alexandru Elisei 2024-01-30 11:58 ` Alexandru Elisei 2024-01-31 4:40 ` Anshuman Khandual 2024-01-31 4:40 ` Anshuman Khandual 2024-01-31 13:27 ` Alexandru Elisei 2024-01-31 13:27 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 07/35] mm: cma: Add CMA_RELEASE_{SUCCESS,FAIL} events Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-29 9:31 ` Anshuman Khandual 2024-01-29 9:31 ` Anshuman Khandual 2024-01-29 11:53 ` Alexandru Elisei 2024-01-29 11:53 ` Alexandru Elisei 2024-01-31 5:59 ` Anshuman Khandual 2024-01-31 5:59 ` Anshuman Khandual 2024-01-25 16:42 ` [PATCH RFC v3 08/35] mm: cma: Introduce cma_alloc_range() Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-30 5:20 ` Anshuman Khandual 2024-01-30 5:20 ` Anshuman Khandual 2024-01-30 11:35 ` Alexandru Elisei 2024-01-30 11:35 ` Alexandru Elisei 2024-01-31 6:24 ` Anshuman Khandual 2024-01-31 6:24 ` Anshuman Khandual 2024-01-31 14:18 ` Alexandru Elisei [this message] 2024-01-31 14:18 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 09/35] mm: cma: Introduce cma_remove_mem() Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-30 5:50 ` Anshuman Khandual 2024-01-30 5:50 ` Anshuman Khandual 2024-01-30 11:33 ` Alexandru Elisei 2024-01-30 11:33 ` Alexandru Elisei 2024-01-31 13:19 ` Anshuman Khandual 2024-01-31 13:19 ` Anshuman Khandual 2024-01-31 13:48 ` Alexandru Elisei 2024-01-31 13:48 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 10/35] mm: cma: Fast track allocating memory when the pages are free Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-30 9:18 ` Anshuman Khandual 2024-01-30 9:18 ` Anshuman Khandual 2024-01-30 11:34 ` Alexandru Elisei 2024-01-30 11:34 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 11/35] mm: Allow an arch to hook into folio allocation when VMA is known Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-26 20:00 ` Peter Collingbourne 2024-01-26 20:00 ` Peter Collingbourne 2024-01-29 11:59 ` Alexandru Elisei 2024-01-29 11:59 ` Alexandru Elisei 2024-01-30 9:55 ` Anshuman Khandual 2024-01-30 9:55 ` Anshuman Khandual 2024-01-30 11:34 ` Alexandru Elisei 2024-01-30 11:34 ` Alexandru Elisei 2024-01-31 6:53 ` Anshuman Khandual 2024-01-31 6:53 ` Anshuman Khandual 2024-01-31 12:22 ` Alexandru Elisei 2024-01-31 12:22 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 12/35] mm: Call arch_swap_prepare_to_restore() before arch_swap_restore() Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-02-01 3:30 ` Anshuman Khandual 2024-02-01 3:30 ` Anshuman Khandual 2024-02-01 17:32 ` Alexandru Elisei 2024-02-01 17:32 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 13/35] mm: memory: Introduce fault-on-access mechanism for pages Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-02-01 5:52 ` Anshuman Khandual 2024-02-01 5:52 ` Anshuman Khandual 2024-02-01 17:36 ` Alexandru Elisei 2024-02-01 17:36 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 14/35] of: fdt: Return the region size in of_flat_dt_translate_address() Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 15/35] of: fdt: Add of_flat_read_u32() Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 16/35] KVM: arm64: Don't deny VM_PFNMAP VMAs when kvm_has_mte() Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 17/35] arm64: mte: Rework naming for tag manipulation functions Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 18/35] arm64: mte: Rename __GFP_ZEROTAGS to __GFP_TAGGED Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 19/35] arm64: mte: Discover tag storage memory Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-26 8:50 ` Krzysztof Kozlowski 2024-01-26 8:50 ` Krzysztof Kozlowski 2024-01-26 17:01 ` Alexandru Elisei 2024-01-26 17:01 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 20/35] arm64: mte: Add tag storage memory to CMA Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 21/35] arm64: mte: Disable dynamic tag storage management if HW KASAN is enabled Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 22/35] arm64: mte: Enable tag storage if CMA areas have been activated Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-02-02 22:30 ` Evgenii Stepanov 2024-02-02 22:30 ` Evgenii Stepanov 2024-02-05 16:30 ` Alexandru Elisei 2024-02-05 16:30 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 23/35] arm64: mte: Try to reserve tag storage in arch_alloc_page() Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-30 0:04 ` Peter Collingbourne 2024-01-30 0:04 ` Peter Collingbourne 2024-01-30 11:38 ` Alexandru Elisei 2024-01-30 11:38 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 24/35] arm64: mte: Perform CMOs for tag blocks Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 25/35] arm64: mte: Reserve tag block for the zero page Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 26/35] arm64: mte: Use fault-on-access to reserve missing tag storage Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 27/35] arm64: mte: Handle tag storage pages mapped in an MTE VMA Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 28/35] arm64: mte: swap: Handle tag restoring when missing tag storage Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-02-02 4:02 ` Peter Collingbourne 2024-02-02 4:02 ` Peter Collingbourne 2024-02-02 14:56 ` Alexandru Elisei 2024-02-02 14:56 ` Alexandru Elisei 2024-02-03 1:32 ` Evgenii Stepanov 2024-02-03 1:32 ` Evgenii Stepanov 2024-02-03 1:52 ` Peter Collingbourne 2024-02-03 1:52 ` Peter Collingbourne 2024-01-25 16:42 ` [PATCH RFC v3 29/35] arm64: mte: copypage: " Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 30/35] arm64: mte: ptrace: Handle pages with " Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-02-01 9:21 ` Anshuman Khandual 2024-02-01 9:21 ` Anshuman Khandual 2024-02-01 17:38 ` Alexandru Elisei 2024-02-01 17:38 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 31/35] khugepaged: arm64: Don't collapse MTE enabled VMAs Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-02-01 8:12 ` Anshuman Khandual 2024-02-01 8:12 ` Anshuman Khandual 2024-02-01 17:38 ` Alexandru Elisei 2024-02-01 17:38 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 32/35] KVM: arm64: mte: Reserve tag storage for virtual machines with MTE Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 33/35] KVM: arm64: mte: Introduce VM_MTE_KVM VMA flag Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 34/35] arm64: mte: Enable dynamic tag storage management Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-25 16:42 ` [PATCH RFC v3 35/35] HACK! arm64: dts: Add fake tag storage to fvp-base-revc.dts Alexandru Elisei 2024-01-25 16:42 ` Alexandru Elisei 2024-01-25 17:01 ` [PATCH RFC v3 00/35] Add support for arm64 MTE dynamic tag storage reuse Steven Rostedt 2024-01-25 17:01 ` Steven Rostedt
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=ZbpWripbKW5MaV8J@raptor \ --to=alexandru.elisei@arm.com \ --cc=akpm@linux-foundation.org \ --cc=anshuman.khandual@arm.com \ --cc=arnd@arndb.de \ --cc=bristot@redhat.com \ --cc=bsegall@google.com \ --cc=catalin.marinas@arm.com \ --cc=david@redhat.com \ --cc=dietmar.eggemann@arm.com \ --cc=eugenis@google.com \ --cc=hughd@google.com \ --cc=hyesoo.yu@samsung.com \ --cc=james.morse@arm.com \ --cc=juri.lelli@redhat.com \ --cc=kcc@google.com \ --cc=kvmarm@lists.linux.dev \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-trace-kernel@vger.kernel.org \ --cc=maz@kernel.org \ --cc=mgorman@suse.de \ --cc=mhiramat@kernel.org \ --cc=mingo@redhat.com \ --cc=oliver.upton@linux.dev \ --cc=pcc@google.com \ --cc=peterz@infradead.org \ --cc=rostedt@goodmis.org \ --cc=rppt@kernel.org \ --cc=steven.price@arm.com \ --cc=suzuki.poulose@arm.com \ --cc=vincent.guittot@linaro.org \ --cc=vincenzo.frascino@arm.com \ --cc=vschneid@redhat.com \ --cc=will@kernel.org \ --cc=yuzenghui@huawei.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.