From: Ard Biesheuvel <ardb@kernel.org> To: Catalin Marinas <catalin.marinas@arm.com> Cc: Herbert Xu <herbert@gondor.apana.org.au>, 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 Memory Management List <linux-mm@kvack.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "David S. Miller" <davem@davemloft.net> Subject: Re: [PATCH 07/10] crypto: Use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN Date: Tue, 19 Apr 2022 23:50:11 +0200 [thread overview] Message-ID: <CAMj1kXEGdPageO3tb2=eLnGAR9-nZtmTGXcGf5CiTQFC4JiXOg@mail.gmail.com> (raw) In-Reply-To: <Yl2Vda/8S7qAvMjC@arm.com> On Mon, 18 Apr 2022 at 18:44, Catalin Marinas <catalin.marinas@arm.com> wrote: > > On Mon, Apr 18, 2022 at 04:37:17PM +0800, Herbert Xu wrote: > > On Sun, Apr 17, 2022 at 05:30:27PM +0100, Catalin Marinas wrote: > > > Do you mean as per Ard's proposal here: > > > > > > https://lore.kernel.org/r/CAMj1kXH0x5Va7Wgs+mU1ONDwwsazOBuN4z4ihVzO2uG-n41Kbg@mail.gmail.com > > > > > > struct crypto_request { > > > union { > > > struct { > > > ... fields ... > > > }; > > > u8 __padding[ARCH_DMA_MINALIGN]; > > > }; > > > void __ctx[] __aligned(CRYPTO_MINALIGN); > > > }; > > > > > > If CRYPTO_MINALIGN is lowered to, say, 8 (to be the same as lowest > > > ARCH_KMALLOC_MINALIGN), the __alignof__(req->__ctx) would be 8. > > > Functions like crypto_tfm_ctx_alignment() will return 8 when what you > > > need is 128. We can change those functions to return ARCH_DMA_MINALIGN > > > instead or always bump cra_alignmask to ARCH_DMA_MINALIGN-1. > > > > OK, at this point I think we need to let the code do the talking :) > > > > I've seen Ard's patches already and I think I understand what your > > needs are. So let me whip up some code to show you guys what I > > think needs to be done. > > BTW before you have a go at this, there's also Linus' idea that does not > change the crypto code (at least not functionally). Of course, you and > Ard can still try to figure out how to reduce the padding but if we go > with Linus' idea of a new GFP_NODMA flag, there won't be any changes to > the crypto code as long as it doesn't pass such flag. So, the options: > > 1. Change ARCH_KMALLOC_MINALIGN to 8 (or ARCH_SLAB_MINALIGN if higher) > while keeping ARCH_DMA_MINALIGN to 128. By default kmalloc() will > honour the 128-byte alignment, unless GDP_NODMA is passed. This still > requires changing CRYPTO_MINALIGN to ARCH_DMA_MINALIGN but there is > no functional change, kmalloc() without the new flag will return > CRYPTO_MINALIGN-aligned pointers. > > 2. Leave ARCH_KMALLOC_MINALIGN as ARCH_DMA_MINALIGN (128) and introduce > a new GFP_PACKED (I think it fits better than 'NODMA') flag that > reduces the minimum kmalloc() below ARCH_KMALLOC_MINALIGN (and > probably at least ARCH_SLAB_MINALIGN). It's equivalent to (1) but > does not touch the crypto code at all. > > (1) and (2) are the same, just minor naming difference. Happy to go with > any of them. They still have the downside that we need to add the new > GFP_ flag to those hotspots that allocate small objects (Arnd provided > an idea on how to find them with ftrace) but at least we know it won't > inadvertently break anything. > I'm not sure GFP_NODMA adds much here. The way I see it, the issue in the crypto code is that we are relying on a ARCH_KMALLOC_ALIGN aligned zero length __ctx[] array for three different things: - ensuring/informing the compiler that top-level request/TFM structures are aligned to ARCH_KMALLOC_ALIGN, - adding padding to ensure that driver context structures that are embedded in those top-level request/TFM structures are sufficiently aligned so that any member C types appear at the expected alignment (but those structures are not usually defined as being aligned to ARCH_KMALLOC_ALIGN) - adding padding to ensure that these driver context structures do not share cache lines with the preceding top-level struct. One thing to note here is that the padding is only necessary when the driver context size > 0, and has nothing to do with the alignment of the top-level struct. Using a single aligned ctx member was a nice way to accomplish all of these when it was introduced, but I think it might be better to get rid of it, and move the padding logic to the static inline helpers instead. So something like struct skcipher_request { ... } CRYPTO_MINALIGN_ATTR; which states/ensures the alignment of the struct, and void *skcipher_request_ctx(struct skcipher_request *req) { return (void *)PTR_ALIGN(req + 1, ARCH_DMA_MINALIGN); } to get at the context struct, instead of using a struct field. Then, we could update skcipher_request_alloc() to only round up sizeof(struct skipher_request) to ARCH_DMA_MINALIGN if the reqsize is >0 to begin with, and if it is, to also round reqsize up to ARCH_DMA_MINALIGN when accessed. That way, we spell out the DMA padding requirements with relying on aligned struct members. If we do it this way, we have a clear distinction between expectations about what kmalloc returns in terms of alignment, and adding padding to influence the placement of the context struct. It also makes it easier to either apply the changes I proposed in the series I sent out a couple of weeks ago, or get rid of DMA alignment for request/TFM structures altogether, if we manage to identify and fix the drivers that are relying on this. In any case, it decouples these two things in a way that allows Catalin to make his kmalloc changes without having to redefine CRYPTO_MINALIGN to ARCH_DMA_MINALIGN. -- Ard.
WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ardb@kernel.org> To: Catalin Marinas <catalin.marinas@arm.com> Cc: Herbert Xu <herbert@gondor.apana.org.au>, 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 Memory Management List <linux-mm@kvack.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "David S. Miller" <davem@davemloft.net> Subject: Re: [PATCH 07/10] crypto: Use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN Date: Tue, 19 Apr 2022 23:50:11 +0200 [thread overview] Message-ID: <CAMj1kXEGdPageO3tb2=eLnGAR9-nZtmTGXcGf5CiTQFC4JiXOg@mail.gmail.com> (raw) In-Reply-To: <Yl2Vda/8S7qAvMjC@arm.com> On Mon, 18 Apr 2022 at 18:44, Catalin Marinas <catalin.marinas@arm.com> wrote: > > On Mon, Apr 18, 2022 at 04:37:17PM +0800, Herbert Xu wrote: > > On Sun, Apr 17, 2022 at 05:30:27PM +0100, Catalin Marinas wrote: > > > Do you mean as per Ard's proposal here: > > > > > > https://lore.kernel.org/r/CAMj1kXH0x5Va7Wgs+mU1ONDwwsazOBuN4z4ihVzO2uG-n41Kbg@mail.gmail.com > > > > > > struct crypto_request { > > > union { > > > struct { > > > ... fields ... > > > }; > > > u8 __padding[ARCH_DMA_MINALIGN]; > > > }; > > > void __ctx[] __aligned(CRYPTO_MINALIGN); > > > }; > > > > > > If CRYPTO_MINALIGN is lowered to, say, 8 (to be the same as lowest > > > ARCH_KMALLOC_MINALIGN), the __alignof__(req->__ctx) would be 8. > > > Functions like crypto_tfm_ctx_alignment() will return 8 when what you > > > need is 128. We can change those functions to return ARCH_DMA_MINALIGN > > > instead or always bump cra_alignmask to ARCH_DMA_MINALIGN-1. > > > > OK, at this point I think we need to let the code do the talking :) > > > > I've seen Ard's patches already and I think I understand what your > > needs are. So let me whip up some code to show you guys what I > > think needs to be done. > > BTW before you have a go at this, there's also Linus' idea that does not > change the crypto code (at least not functionally). Of course, you and > Ard can still try to figure out how to reduce the padding but if we go > with Linus' idea of a new GFP_NODMA flag, there won't be any changes to > the crypto code as long as it doesn't pass such flag. So, the options: > > 1. Change ARCH_KMALLOC_MINALIGN to 8 (or ARCH_SLAB_MINALIGN if higher) > while keeping ARCH_DMA_MINALIGN to 128. By default kmalloc() will > honour the 128-byte alignment, unless GDP_NODMA is passed. This still > requires changing CRYPTO_MINALIGN to ARCH_DMA_MINALIGN but there is > no functional change, kmalloc() without the new flag will return > CRYPTO_MINALIGN-aligned pointers. > > 2. Leave ARCH_KMALLOC_MINALIGN as ARCH_DMA_MINALIGN (128) and introduce > a new GFP_PACKED (I think it fits better than 'NODMA') flag that > reduces the minimum kmalloc() below ARCH_KMALLOC_MINALIGN (and > probably at least ARCH_SLAB_MINALIGN). It's equivalent to (1) but > does not touch the crypto code at all. > > (1) and (2) are the same, just minor naming difference. Happy to go with > any of them. They still have the downside that we need to add the new > GFP_ flag to those hotspots that allocate small objects (Arnd provided > an idea on how to find them with ftrace) but at least we know it won't > inadvertently break anything. > I'm not sure GFP_NODMA adds much here. The way I see it, the issue in the crypto code is that we are relying on a ARCH_KMALLOC_ALIGN aligned zero length __ctx[] array for three different things: - ensuring/informing the compiler that top-level request/TFM structures are aligned to ARCH_KMALLOC_ALIGN, - adding padding to ensure that driver context structures that are embedded in those top-level request/TFM structures are sufficiently aligned so that any member C types appear at the expected alignment (but those structures are not usually defined as being aligned to ARCH_KMALLOC_ALIGN) - adding padding to ensure that these driver context structures do not share cache lines with the preceding top-level struct. One thing to note here is that the padding is only necessary when the driver context size > 0, and has nothing to do with the alignment of the top-level struct. Using a single aligned ctx member was a nice way to accomplish all of these when it was introduced, but I think it might be better to get rid of it, and move the padding logic to the static inline helpers instead. So something like struct skcipher_request { ... } CRYPTO_MINALIGN_ATTR; which states/ensures the alignment of the struct, and void *skcipher_request_ctx(struct skcipher_request *req) { return (void *)PTR_ALIGN(req + 1, ARCH_DMA_MINALIGN); } to get at the context struct, instead of using a struct field. Then, we could update skcipher_request_alloc() to only round up sizeof(struct skipher_request) to ARCH_DMA_MINALIGN if the reqsize is >0 to begin with, and if it is, to also round reqsize up to ARCH_DMA_MINALIGN when accessed. That way, we spell out the DMA padding requirements with relying on aligned struct members. If we do it this way, we have a clear distinction between expectations about what kmalloc returns in terms of alignment, and adding padding to influence the placement of the context struct. It also makes it easier to either apply the changes I proposed in the series I sent out a couple of weeks ago, or get rid of DMA alignment for request/TFM structures altogether, if we manage to identify and fix the drivers that are relying on this. In any case, it decouples these two things in a way that allows Catalin to make his kmalloc changes without having to redefine CRYPTO_MINALIGN to ARCH_DMA_MINALIGN. -- Ard. _______________________________________________ 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-19 21:50 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 [this message] 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 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='CAMj1kXEGdPageO3tb2=eLnGAR9-nZtmTGXcGf5CiTQFC4JiXOg@mail.gmail.com' \ --to=ardb@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=arnd@arndb.de \ --cc=catalin.marinas@arm.com \ --cc=davem@davemloft.net \ --cc=gregkh@linuxfoundation.org \ --cc=herbert@gondor.apana.org.au \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=maz@kernel.org \ --cc=torvalds@linux-foundation.org \ --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.