From: Catalin Marinas <catalin.marinas@arm.com> To: Vlastimil Babka <vbabka@suse.cz> Cc: Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Andrew Morton <akpm@linux-foundation.org>, Linus Torvalds <torvalds@linux-foundation.org>, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Herbert Xu <herbert@gondor.apana.org.au>, "David S. Miller" <davem@davemloft.net>, Mark Brown <broonie@kernel.org>, Alasdair Kergon <agk@redhat.com>, Mike Snitzer <snitzer@kernel.org>, Daniel Vetter <daniel@ffwll.ch>, "Rafael J. Wysocki" <rafael@kernel.org>, Christoph Lameter <cl@linux.com>, David Rientjes <rientjes@google.com>, Pekka Enberg <penberg@kernel.org>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, Roman Gushchin <guro@fb.com>, Hyeonggon Yoo <42.hyeyoo@gmail.com>, Rustam Kovhaev <rkovhaev@gmail.com>, David Laight <David.Laight@aculab.com> Subject: Re: [PATCH 00/10] mm, arm64: Reduce ARCH_KMALLOC_MINALIGN below the cache line size Date: Thu, 7 Apr 2022 18:48:57 +0100 [thread overview] Message-ID: <Yk8kCQnSa0F5yIfC@arm.com> (raw) In-Reply-To: <0966c4b0-6fff-3283-71c3-2d4e211f7385@suse.cz> On Thu, Apr 07, 2022 at 04:40:15PM +0200, Vlastimil Babka wrote: > On 4/5/22 15:57, Catalin Marinas wrote: > > This series is beneficial to arm64 even if it's only reducing the > > kmalloc() minimum alignment to 64. While it would be nice to reduce this > > further to 8 (or 16) on SoCs known to be fully DMA coherent, detecting > > this is via arch_setup_dma_ops() is problematic, especially with late > > probed devices. I'd leave it for an additional RFC series on top of > > this (there are ideas like bounce buffering for non-coherent devices if > > the SoC was deemed coherent). [...] > - due to ARCH_KMALLOC_MINALIGN and dma guarantees we should return > allocations aligned to ARCH_KMALLOC_MINALIGN and the prepended size header > should also not share their ARCH_KMALLOC_MINALIGN block with another > (shorter) allocation that has a different lifetime, for the dma coherency > reasons > - this is very wasteful especially with the 128 bytes alignment, and seems > we already violate it in some scenarios anyway [2]. Extending this to all > objects would be even more wasteful. > > So this series would help here, especially if we can get to the 8/16 size. If we get to 8/16 size, it would only be for platforms that are fully coherent. Otherwise, with non-coherent DMA, the minimum kmalloc() alignment would still be the cache line size (typically 64) even if ARCH_KMALLOC_MINALIGN is 8. IIUC your point is that if ARCH_KMALLOC_MINALIGN is 8, kmalloc() could return pointers 8-byte aligned only as long as DMA safety is preserved (like not sharing the rest of the cache line with anything other writers). > But now I also wonder if keeping the name and meaning of "MINALIGN" is in > fact misleading and unnecessarily constraining us? What this is really about > is "granularity of exclusive access", no? Not necessarily. Yes, in lots of cases it is about granularity of access but there are others where the code does need the pointer returned aligned to ARCH_DMA_MINALIGN (currently via ARCH_KMALLOC_MINALIGN). Crypto seems to have such requirement (see the sub-thread with Herbert). Some (all?) callers ask kmalloc() for the aligned size and there's an expectation that if the size is a multiple of a power of two, kmalloc() will return a pointer aligned to that power of two. I think we need to preserve these semantics which may lead to some more wastage if you add the header (e.g. a size of 3*64 returns a pointer either aligned to 192 or 256). > Let's say the dma granularity is 64bytes, and there's a kmalloc(56). In your example, the size is not a power of two (or multiple of), so I guess there's no expectation for a 64-byte alignment (it can be 8) unless DMA is involved. See below. > If SLOB find a 64-bytes aligned block, uses the first 8 bytes for the > size header and returns the remaining 56 bytes, then the returned > pointer is not *aligned* to 64 bytes, but it's still aligned enough > for cpu accesses (which need only e.g. 8), and non-coherent dma should > be also safe because nobody will be accessing the 8 bytes header, > until the user of the object calls kfree() which should happen only > when it's done with any dma operations. Is my reasoning correct and > would this be safe? From the DMA perspective, it's not safe currently. Let's say we have an inbound DMA transfer, the DMA API will invalidate the cache line prior to DMA. In arm64 terms, it means that the cache line is discarded, not flushed to memory. If the first 8 bytes had not been written back to RAM, they'd be lost. If we can guarantee that no CPU write happens to the cache line during the DMA transfer, we can change the DMA mapping operation to do a clean+invalidate (flush the cacheline to RAM) first. I guess this could be done with an IS_ENABLED(CONFIG_SLOB) check. -- Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com> To: Vlastimil Babka <vbabka@suse.cz> Cc: Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Andrew Morton <akpm@linux-foundation.org>, Linus Torvalds <torvalds@linux-foundation.org>, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Herbert Xu <herbert@gondor.apana.org.au>, "David S. Miller" <davem@davemloft.net>, Mark Brown <broonie@kernel.org>, Alasdair Kergon <agk@redhat.com>, Mike Snitzer <snitzer@kernel.org>, Daniel Vetter <daniel@ffwll.ch>, "Rafael J. Wysocki" <rafael@kernel.org>, Christoph Lameter <cl@linux.com>, David Rientjes <rientjes@google.com>, Pekka Enberg <penberg@kernel.org>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, Roman Gushchin <guro@fb.com>, Hyeonggon Yoo <42.hyeyoo@gmail.com>, Rustam Kovhaev <rkovhaev@gmail.com>, David Laight <David.Laight@aculab.com> Subject: Re: [PATCH 00/10] mm, arm64: Reduce ARCH_KMALLOC_MINALIGN below the cache line size Date: Thu, 7 Apr 2022 18:48:57 +0100 [thread overview] Message-ID: <Yk8kCQnSa0F5yIfC@arm.com> (raw) In-Reply-To: <0966c4b0-6fff-3283-71c3-2d4e211f7385@suse.cz> On Thu, Apr 07, 2022 at 04:40:15PM +0200, Vlastimil Babka wrote: > On 4/5/22 15:57, Catalin Marinas wrote: > > This series is beneficial to arm64 even if it's only reducing the > > kmalloc() minimum alignment to 64. While it would be nice to reduce this > > further to 8 (or 16) on SoCs known to be fully DMA coherent, detecting > > this is via arch_setup_dma_ops() is problematic, especially with late > > probed devices. I'd leave it for an additional RFC series on top of > > this (there are ideas like bounce buffering for non-coherent devices if > > the SoC was deemed coherent). [...] > - due to ARCH_KMALLOC_MINALIGN and dma guarantees we should return > allocations aligned to ARCH_KMALLOC_MINALIGN and the prepended size header > should also not share their ARCH_KMALLOC_MINALIGN block with another > (shorter) allocation that has a different lifetime, for the dma coherency > reasons > - this is very wasteful especially with the 128 bytes alignment, and seems > we already violate it in some scenarios anyway [2]. Extending this to all > objects would be even more wasteful. > > So this series would help here, especially if we can get to the 8/16 size. If we get to 8/16 size, it would only be for platforms that are fully coherent. Otherwise, with non-coherent DMA, the minimum kmalloc() alignment would still be the cache line size (typically 64) even if ARCH_KMALLOC_MINALIGN is 8. IIUC your point is that if ARCH_KMALLOC_MINALIGN is 8, kmalloc() could return pointers 8-byte aligned only as long as DMA safety is preserved (like not sharing the rest of the cache line with anything other writers). > But now I also wonder if keeping the name and meaning of "MINALIGN" is in > fact misleading and unnecessarily constraining us? What this is really about > is "granularity of exclusive access", no? Not necessarily. Yes, in lots of cases it is about granularity of access but there are others where the code does need the pointer returned aligned to ARCH_DMA_MINALIGN (currently via ARCH_KMALLOC_MINALIGN). Crypto seems to have such requirement (see the sub-thread with Herbert). Some (all?) callers ask kmalloc() for the aligned size and there's an expectation that if the size is a multiple of a power of two, kmalloc() will return a pointer aligned to that power of two. I think we need to preserve these semantics which may lead to some more wastage if you add the header (e.g. a size of 3*64 returns a pointer either aligned to 192 or 256). > Let's say the dma granularity is 64bytes, and there's a kmalloc(56). In your example, the size is not a power of two (or multiple of), so I guess there's no expectation for a 64-byte alignment (it can be 8) unless DMA is involved. See below. > If SLOB find a 64-bytes aligned block, uses the first 8 bytes for the > size header and returns the remaining 56 bytes, then the returned > pointer is not *aligned* to 64 bytes, but it's still aligned enough > for cpu accesses (which need only e.g. 8), and non-coherent dma should > be also safe because nobody will be accessing the 8 bytes header, > until the user of the object calls kfree() which should happen only > when it's done with any dma operations. Is my reasoning correct and > would this be safe? From the DMA perspective, it's not safe currently. Let's say we have an inbound DMA transfer, the DMA API will invalidate the cache line prior to DMA. In arm64 terms, it means that the cache line is discarded, not flushed to memory. If the first 8 bytes had not been written back to RAM, they'd be lost. If we can guarantee that no CPU write happens to the cache line during the DMA transfer, we can change the DMA mapping operation to do a clean+invalidate (flush the cacheline to RAM) first. I guess this could be done with an IS_ENABLED(CONFIG_SLOB) check. -- Catalin _______________________________________________ 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:[~2022-04-07 17:49 UTC|newest] Thread overview: 287+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-05 13:57 [PATCH 00/10] mm, arm64: Reduce ARCH_KMALLOC_MINALIGN below the cache line size Catalin Marinas 2022-04-05 13:57 ` Catalin Marinas 2022-04-05 13:57 ` [PATCH 01/10] mm/slab: Decouple ARCH_KMALLOC_MINALIGN from ARCH_DMA_MINALIGN Catalin Marinas 2022-04-05 13:57 ` Catalin Marinas 2022-04-05 23:59 ` Hyeonggon Yoo 2022-04-05 23:59 ` Hyeonggon Yoo 2022-04-06 7:29 ` Arnd Bergmann 2022-04-06 7:29 ` Arnd Bergmann 2022-04-06 12:09 ` Hyeonggon Yoo 2022-04-06 12:09 ` Hyeonggon Yoo 2022-04-06 8:53 ` Catalin Marinas 2022-04-06 8:53 ` Catalin Marinas 2022-04-06 2:01 ` kernel test robot 2022-04-06 8:56 ` Catalin Marinas 2022-04-06 8:56 ` Catalin Marinas 2022-04-06 12:18 ` [kbuild-all] " Chen, Rong A 2022-04-08 6:42 ` Hyeonggon Yoo 2022-04-08 6:42 ` Hyeonggon Yoo 2022-04-08 9:06 ` Hyeonggon Yoo 2022-04-08 9:06 ` Hyeonggon Yoo 2022-04-08 9:11 ` Catalin Marinas 2022-04-08 9:11 ` Catalin Marinas 2022-04-11 10:37 ` Hyeonggon Yoo 2022-04-11 10:37 ` Hyeonggon Yoo 2022-04-11 14:02 ` Catalin Marinas 2022-04-11 14:02 ` Catalin Marinas 2022-04-05 13:57 ` [PATCH 02/10] drivers/base: Use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN Catalin Marinas 2022-04-05 13:57 ` Catalin Marinas 2022-04-11 14:57 ` Andy Shevchenko 2022-04-11 14:57 ` Andy Shevchenko 2022-04-11 17:39 ` Catalin Marinas 2022-04-11 17:39 ` Catalin Marinas 2022-04-05 13:57 ` [PATCH 03/10] drivers/gpu: " Catalin Marinas 2022-04-05 13:57 ` Catalin Marinas 2022-04-05 13:57 ` [PATCH 04/10] drivers/md: " Catalin Marinas 2022-04-05 13:57 ` Catalin Marinas 2022-04-05 13:57 ` [PATCH 05/10] drivers/spi: " Catalin Marinas 2022-04-05 13:57 ` Catalin Marinas 2022-04-05 14:05 ` Mark Brown 2022-04-05 14:05 ` Mark Brown 2022-04-05 13:57 ` [PATCH 06/10] drivers/usb: " Catalin Marinas 2022-04-05 13:57 ` Catalin Marinas 2022-04-05 13:57 ` [PATCH 07/10] crypto: " Catalin Marinas 2022-04-05 13:57 ` Catalin Marinas 2022-04-05 22:57 ` Herbert Xu 2022-04-05 22:57 ` Herbert Xu 2022-04-06 6:53 ` Ard Biesheuvel 2022-04-06 6:53 ` Ard Biesheuvel 2022-04-06 8:49 ` Catalin Marinas 2022-04-06 8:49 ` Catalin Marinas 2022-04-06 9:41 ` Ard Biesheuvel 2022-04-06 9:41 ` Ard Biesheuvel 2022-04-07 4:30 ` Herbert Xu 2022-04-07 4:30 ` Herbert Xu 2022-04-07 11:01 ` Catalin Marinas 2022-04-07 11:01 ` Catalin Marinas 2022-04-07 11:40 ` Herbert Xu 2022-04-07 11:40 ` Herbert Xu 2022-04-07 16:28 ` Catalin Marinas 2022-04-07 16:28 ` Catalin Marinas 2022-04-08 3:25 ` Herbert Xu 2022-04-08 3:25 ` Herbert Xu 2022-04-08 9:04 ` Catalin Marinas 2022-04-08 9:04 ` Catalin Marinas 2022-04-08 9:11 ` Herbert Xu 2022-04-08 9:11 ` Herbert Xu 2022-04-12 9:32 ` Catalin Marinas 2022-04-12 9:32 ` Catalin Marinas 2022-04-12 9:40 ` Herbert Xu 2022-04-12 9:40 ` Herbert Xu 2022-04-12 10:02 ` Catalin Marinas 2022-04-12 10:02 ` Catalin Marinas 2022-04-12 10:18 ` Herbert Xu 2022-04-12 10:18 ` Herbert Xu 2022-04-12 12:31 ` Catalin Marinas 2022-04-12 12:31 ` Catalin Marinas 2022-04-12 22:01 ` Ard Biesheuvel 2022-04-12 22:01 ` Ard Biesheuvel 2022-04-13 8:47 ` Catalin Marinas 2022-04-13 8:47 ` Catalin Marinas 2022-04-13 19:53 ` Linus Torvalds 2022-04-13 19:53 ` Linus Torvalds 2022-04-14 5:38 ` Greg Kroah-Hartman 2022-04-14 5:38 ` Greg Kroah-Hartman 2022-04-14 13:52 ` Ard Biesheuvel 2022-04-14 13:52 ` Ard Biesheuvel 2022-04-14 14:27 ` Greg Kroah-Hartman 2022-04-14 14:27 ` Greg Kroah-Hartman 2022-04-14 14:36 ` Ard Biesheuvel 2022-04-14 14:36 ` Ard Biesheuvel 2022-04-14 14:52 ` Greg Kroah-Hartman 2022-04-14 14:52 ` Greg Kroah-Hartman 2022-04-14 15:01 ` Ard Biesheuvel 2022-04-14 15:01 ` Ard Biesheuvel 2022-04-14 15:10 ` Ard Biesheuvel 2022-04-14 15:10 ` Ard Biesheuvel 2022-04-14 19:49 ` Catalin Marinas 2022-04-14 19:49 ` Catalin Marinas 2022-04-14 22:25 ` Linus Torvalds 2022-04-14 22:25 ` Linus Torvalds 2022-04-15 6:03 ` Ard Biesheuvel 2022-04-15 6:03 ` Ard Biesheuvel 2022-04-15 11:09 ` Arnd Bergmann 2022-04-15 11:09 ` Arnd Bergmann 2022-04-16 9:42 ` Catalin Marinas 2022-04-16 9:42 ` Catalin Marinas 2022-04-20 19:07 ` Catalin Marinas 2022-04-20 19:07 ` Catalin Marinas 2022-04-20 19:33 ` Linus Torvalds 2022-04-20 19:33 ` Linus Torvalds 2022-04-14 14:30 ` Ard Biesheuvel 2022-04-14 14:30 ` Ard Biesheuvel 2022-04-15 6:51 ` Herbert Xu 2022-04-15 6:51 ` Herbert Xu 2022-04-15 7:49 ` Ard Biesheuvel 2022-04-15 7:49 ` Ard Biesheuvel 2022-04-15 7:51 ` Herbert Xu 2022-04-15 7:51 ` Herbert Xu 2022-04-15 8:05 ` Ard Biesheuvel 2022-04-15 8:05 ` Ard Biesheuvel 2022-04-15 8:12 ` Herbert Xu 2022-04-15 8:12 ` Herbert Xu 2022-04-15 9:51 ` Ard Biesheuvel 2022-04-15 9:51 ` Ard Biesheuvel 2022-04-15 10:04 ` Ard Biesheuvel 2022-04-15 10:04 ` Ard Biesheuvel 2022-04-15 10:12 ` Herbert Xu 2022-04-15 10:12 ` Herbert Xu 2022-04-15 10:22 ` Ard Biesheuvel 2022-04-15 10:22 ` Ard Biesheuvel 2022-04-15 10:45 ` Herbert Xu 2022-04-15 10:45 ` Herbert Xu 2022-04-15 11:38 ` Ard Biesheuvel 2022-04-15 11:38 ` Ard Biesheuvel 2022-04-17 8:08 ` Herbert Xu 2022-04-17 8:08 ` Herbert Xu 2022-04-17 8:31 ` Catalin Marinas 2022-04-17 8:31 ` Catalin Marinas 2022-04-17 8:35 ` Herbert Xu 2022-04-17 8:35 ` Herbert Xu 2022-04-17 8:50 ` Catalin Marinas 2022-04-17 8:50 ` Catalin Marinas 2022-04-17 8:58 ` Herbert Xu 2022-04-17 8:58 ` Herbert Xu 2022-04-17 16:30 ` Catalin Marinas 2022-04-17 16:30 ` Catalin Marinas 2022-04-18 8:37 ` Herbert Xu 2022-04-18 8:37 ` Herbert Xu 2022-04-18 9:19 ` Catalin Marinas 2022-04-18 9:19 ` Catalin Marinas 2022-04-18 16:44 ` Catalin Marinas 2022-04-18 16:44 ` Catalin Marinas 2022-04-19 21:50 ` Ard Biesheuvel 2022-04-19 21:50 ` Ard Biesheuvel 2022-04-20 10:36 ` Catalin Marinas 2022-04-20 10:36 ` Catalin Marinas 2022-04-20 11:29 ` Arnd Bergmann 2022-04-20 11:29 ` Arnd Bergmann 2022-04-21 7:20 ` Christoph Hellwig 2022-04-21 7:20 ` Christoph Hellwig 2022-04-21 7:36 ` Arnd Bergmann 2022-04-21 7:36 ` Arnd Bergmann 2022-04-21 7:44 ` Christoph Hellwig 2022-04-21 7:44 ` Christoph Hellwig 2022-04-21 8:05 ` Ard Biesheuvel 2022-04-21 8:05 ` Ard Biesheuvel 2022-04-21 11:06 ` Catalin Marinas 2022-04-21 11:06 ` Catalin Marinas 2022-04-21 12:28 ` Arnd Bergmann 2022-04-21 12:28 ` Arnd Bergmann 2022-04-21 13:25 ` Catalin Marinas 2022-04-21 13:25 ` Catalin Marinas 2022-04-21 13:47 ` Arnd Bergmann 2022-04-21 13:47 ` Arnd Bergmann 2022-04-21 14:44 ` Catalin Marinas 2022-04-21 14:44 ` Catalin Marinas 2022-04-21 14:47 ` Arnd Bergmann 2022-04-21 14:47 ` Arnd Bergmann 2022-05-10 11:03 ` [RFC PATCH 0/7] crypto: Add helpers for allocating with DMA alignment Herbert Xu 2022-05-10 11:03 ` Herbert Xu 2022-05-10 11:07 ` [RFC PATCH 1/7] crypto: Prepare to move crypto_tfm_ctx Herbert Xu 2022-05-10 11:07 ` Herbert Xu 2022-05-10 11:07 ` [RFC PATCH 2/7] crypto: api - Add crypto_tfm_ctx_dma Herbert Xu 2022-05-10 11:07 ` Herbert Xu 2022-05-10 17:10 ` Catalin Marinas 2022-05-10 17:10 ` Catalin Marinas 2022-05-12 3:57 ` Herbert Xu 2022-05-12 3:57 ` Herbert Xu 2022-05-10 11:07 ` [RFC PATCH 3/7] crypto: aead - Add ctx helpers with DMA alignment Herbert Xu 2022-05-10 11:07 ` Herbert Xu 2022-05-10 11:07 ` [RFC PATCH 4/7] crypto: hash " Herbert Xu 2022-05-10 11:07 ` Herbert Xu 2022-05-10 11:07 ` [RFC PATCH 5/7] crypto: skcipher " Herbert Xu 2022-05-10 11:07 ` Herbert Xu 2022-05-10 11:07 ` [RFC PATCH 6/7] crypto: api - Increase MAX_ALGAPI_ALIGNMASK to 127 Herbert Xu 2022-05-10 11:07 ` Herbert Xu 2022-05-10 11:07 ` [RFC PATCH 7/7] crypto: caam - Explicitly request DMA alignment Herbert Xu 2022-05-10 11:07 ` Herbert Xu 2022-04-15 12:18 ` [PATCH 07/10] crypto: Use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN Catalin Marinas 2022-04-15 12:18 ` Catalin Marinas 2022-04-15 12:25 ` Ard Biesheuvel 2022-04-15 12:25 ` Ard Biesheuvel 2022-04-15 9:51 ` Catalin Marinas 2022-04-15 9:51 ` Catalin Marinas 2022-04-15 12:31 ` Catalin Marinas 2022-04-15 12:31 ` Catalin Marinas 2022-04-17 8:11 ` Herbert Xu 2022-04-17 8:11 ` Herbert Xu 2022-04-17 8:38 ` Catalin Marinas 2022-04-17 8:38 ` Catalin Marinas 2022-04-17 8:43 ` Herbert Xu 2022-04-17 8:43 ` Herbert Xu 2022-04-17 16:29 ` Catalin Marinas 2022-04-17 16:29 ` Catalin Marinas 2022-07-15 22:23 ` Isaac Manjarres 2022-07-15 22:23 ` Isaac Manjarres 2022-07-16 3:25 ` Herbert Xu 2022-07-16 3:25 ` Herbert Xu 2022-07-18 17:53 ` Catalin Marinas 2022-07-18 17:53 ` Catalin Marinas 2022-09-21 0:47 ` Isaac Manjarres 2022-09-21 0:47 ` Isaac Manjarres 2022-09-30 18:32 ` Catalin Marinas 2022-09-30 18:32 ` Catalin Marinas 2022-09-30 19:35 ` Linus Torvalds 2022-09-30 19:35 ` Linus Torvalds 2022-10-01 22:29 ` Catalin Marinas 2022-10-01 22:29 ` Catalin Marinas 2022-10-02 17:00 ` Linus Torvalds 2022-10-02 17:00 ` Linus Torvalds 2022-10-02 22:08 ` Ard Biesheuvel 2022-10-02 22:08 ` Ard Biesheuvel 2022-10-02 22:24 ` Linus Torvalds 2022-10-02 22:24 ` Linus Torvalds 2022-10-03 17:39 ` Catalin Marinas 2022-10-03 17:39 ` Catalin Marinas 2022-10-12 17:45 ` Isaac Manjarres 2022-10-12 17:45 ` Isaac Manjarres 2022-10-13 16:57 ` Catalin Marinas 2022-10-13 16:57 ` Catalin Marinas 2022-10-13 18:58 ` Saravana Kannan 2022-10-13 18:58 ` Saravana Kannan 2022-10-14 16:25 ` Catalin Marinas 2022-10-14 16:25 ` Catalin Marinas 2022-10-14 20:23 ` Saravana Kannan 2022-10-14 20:23 ` Saravana Kannan 2022-10-14 20:44 ` Linus Torvalds 2022-10-14 20:44 ` Linus Torvalds 2022-10-16 21:37 ` Catalin Marinas 2022-10-16 21:37 ` Catalin Marinas 2022-04-12 10:20 ` Catalin Marinas 2022-04-12 10:20 ` Catalin Marinas 2022-04-07 6:14 ` Muchun Song 2022-04-07 6:14 ` Muchun Song 2022-04-07 9:25 ` Catalin Marinas 2022-04-07 9:25 ` Catalin Marinas 2022-04-07 10:00 ` Muchun Song 2022-04-07 10:00 ` Muchun Song 2022-04-07 11:06 ` Catalin Marinas 2022-04-07 11:06 ` Catalin Marinas 2022-04-05 13:57 ` [PATCH 08/10] mm/slab: Allow dynamic kmalloc() minimum alignment Catalin Marinas 2022-04-05 13:57 ` Catalin Marinas 2022-04-07 3:46 ` Hyeonggon Yoo 2022-04-07 3:46 ` Hyeonggon Yoo 2022-04-07 8:50 ` Catalin Marinas 2022-04-07 8:50 ` Catalin Marinas 2022-04-07 9:18 ` Hyeonggon Yoo 2022-04-07 9:18 ` Hyeonggon Yoo 2022-04-07 9:35 ` Catalin Marinas 2022-04-07 9:35 ` Catalin Marinas 2022-04-07 12:26 ` Hyeonggon Yoo 2022-04-07 12:26 ` Hyeonggon Yoo 2022-04-11 11:55 ` Hyeonggon Yoo 2022-04-11 11:55 ` Hyeonggon Yoo 2022-04-05 13:57 ` [PATCH 09/10] mm/slab: Simplify create_kmalloc_cache() args and make it static Catalin Marinas 2022-04-05 13:57 ` Catalin Marinas 2022-04-06 5:35 ` kernel test robot 2022-04-06 8:57 ` Catalin Marinas 2022-04-06 8:57 ` Catalin Marinas 2022-04-05 13:57 ` [PATCH 10/10] arm64: Enable dynamic kmalloc() minimum alignment Catalin Marinas 2022-04-05 13:57 ` Catalin Marinas 2022-04-07 14:40 ` [PATCH 00/10] mm, arm64: Reduce ARCH_KMALLOC_MINALIGN below the cache line size Vlastimil Babka 2022-04-07 14:40 ` Vlastimil Babka 2022-04-07 17:48 ` Catalin Marinas [this message] 2022-04-07 17:48 ` Catalin Marinas 2022-04-08 14:37 ` Vlastimil Babka 2022-04-08 14:37 ` Vlastimil Babka
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=Yk8kCQnSa0F5yIfC@arm.com \ --to=catalin.marinas@arm.com \ --cc=42.hyeyoo@gmail.com \ --cc=David.Laight@aculab.com \ --cc=agk@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=arnd@arndb.de \ --cc=broonie@kernel.org \ --cc=cl@linux.com \ --cc=daniel@ffwll.ch \ --cc=davem@davemloft.net \ --cc=gregkh@linuxfoundation.org \ --cc=guro@fb.com \ --cc=herbert@gondor.apana.org.au \ --cc=iamjoonsoo.kim@lge.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=maz@kernel.org \ --cc=penberg@kernel.org \ --cc=rafael@kernel.org \ --cc=rientjes@google.com \ --cc=rkovhaev@gmail.com \ --cc=snitzer@kernel.org \ --cc=torvalds@linux-foundation.org \ --cc=vbabka@suse.cz \ --cc=will@kernel.org \ /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.