From: Ard Biesheuvel <ardb@kernel.org> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: Catalin Marinas <catalin.marinas@arm.com>, 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>, 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: Fri, 15 Apr 2022 08:03:54 +0200 [thread overview] Message-ID: <CAMj1kXGA4NH-Kg6rWRq2kUAsefwrOGUqTp47aFQTeaQoSB_1Cg@mail.gmail.com> (raw) In-Reply-To: <CAHk-=wjwupOLq3xh8z02CpXe8-=Lb_z0kXXQJYQ5YaQPpi3MiA@mail.gmail.com> On Fri, 15 Apr 2022 at 00:26, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Thu, Apr 14, 2022 at 12:49 PM Catalin Marinas > <catalin.marinas@arm.com> wrote: > > > > It's a lot worse, ARCH_KMALLOC_MINALIGN is currently 128 bytes on arm64. > > I want to at least get it down to 64 with this series while preserving > > the current kmalloc() semantics. > > So here's a thought - maybe we could do the reverse of GFP_DMA, and > add a flag to the places that want small allocations and know they > don't need DMA? > > Because even 64 bytes is _huge_ for those small allocations. And 128 > bytes is just insane. > > Maybe we don't have a ton of them, but I just checked my desktop, and > if my laptop had 17k 8-byte allocation, on my desktop it's currently > sitting at 43k of them. And I've got a lot of 16- and 32-byte ones > too: > > kmalloc-32 51529 51712 32 128 1 : > kmalloc-16 45056 45056 16 256 1 : > kmalloc-8 43008 43008 8 512 1 : > > Don't ask me what they are. It's probably fairly easy to find out, and > it's probably something silly like sysfs private pointer data or > whatever. > > If I did my math right, with a 128-byte minimum allocation, that is > 16MB of wasted memory. > > Yeah, yeah, I've got 64GB or RAM in this thing, and there are things > that take a lot more memory than the above (mem_map etc), and 64MB is > peanuts at just 0.1% of RAM. > Actually, I think the impact on D-cache efficiency is a much bigger concern, although I don't have any data to back that up. On arm64, every 8 byte allocation takes up an entire cacheline, pushing out other data that we could meaningfully keep there. And the doubling to 128 that is unnecessary on most arm64 systems probably has an additional negative effect, as it means those allocations are heavily skewed to use even indexes into the cache sets, causing extra contention. > Maybe nobody cares. But I really feel bad about that kind of egregious > waste. The mem_map[] array may be big, it may use 1.5% of the memory I > have, but at least it *does* something. > > And it could be that if I have 150k of those smallish allocations, a > server with lots of active users might have millions. Not having > looked at where they come from, maybe that isn't the case, but it > *might* be. > > Maybe adding something like a > > static int warn_every_1k = 0; > WARN_ON(size < 32 && (1023 & ++warn_every_1k)); > > to kmalloc() would give us a statistical view of "lots of these small > allocations" thing, and we could add GFP_NODMA to them. There probably > aren't that many places that have those small allocations, and it's > certainly safer to annotate "this is not for DMA" than have the > requirement that all DMA allocations must be marked. > > Then just teach kmalloc() something like > > align = (gfp_flags & __GFP_NODMA) ? 8 : 128; > > on arm. > Sounds like a lot of churn as well, tbh. But perhaps there are a few hot spots that we can fix that would alleviate the bulk of the issue, who knows?
WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ardb@kernel.org> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: Catalin Marinas <catalin.marinas@arm.com>, 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>, 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: Fri, 15 Apr 2022 08:03:54 +0200 [thread overview] Message-ID: <CAMj1kXGA4NH-Kg6rWRq2kUAsefwrOGUqTp47aFQTeaQoSB_1Cg@mail.gmail.com> (raw) In-Reply-To: <CAHk-=wjwupOLq3xh8z02CpXe8-=Lb_z0kXXQJYQ5YaQPpi3MiA@mail.gmail.com> On Fri, 15 Apr 2022 at 00:26, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Thu, Apr 14, 2022 at 12:49 PM Catalin Marinas > <catalin.marinas@arm.com> wrote: > > > > It's a lot worse, ARCH_KMALLOC_MINALIGN is currently 128 bytes on arm64. > > I want to at least get it down to 64 with this series while preserving > > the current kmalloc() semantics. > > So here's a thought - maybe we could do the reverse of GFP_DMA, and > add a flag to the places that want small allocations and know they > don't need DMA? > > Because even 64 bytes is _huge_ for those small allocations. And 128 > bytes is just insane. > > Maybe we don't have a ton of them, but I just checked my desktop, and > if my laptop had 17k 8-byte allocation, on my desktop it's currently > sitting at 43k of them. And I've got a lot of 16- and 32-byte ones > too: > > kmalloc-32 51529 51712 32 128 1 : > kmalloc-16 45056 45056 16 256 1 : > kmalloc-8 43008 43008 8 512 1 : > > Don't ask me what they are. It's probably fairly easy to find out, and > it's probably something silly like sysfs private pointer data or > whatever. > > If I did my math right, with a 128-byte minimum allocation, that is > 16MB of wasted memory. > > Yeah, yeah, I've got 64GB or RAM in this thing, and there are things > that take a lot more memory than the above (mem_map etc), and 64MB is > peanuts at just 0.1% of RAM. > Actually, I think the impact on D-cache efficiency is a much bigger concern, although I don't have any data to back that up. On arm64, every 8 byte allocation takes up an entire cacheline, pushing out other data that we could meaningfully keep there. And the doubling to 128 that is unnecessary on most arm64 systems probably has an additional negative effect, as it means those allocations are heavily skewed to use even indexes into the cache sets, causing extra contention. > Maybe nobody cares. But I really feel bad about that kind of egregious > waste. The mem_map[] array may be big, it may use 1.5% of the memory I > have, but at least it *does* something. > > And it could be that if I have 150k of those smallish allocations, a > server with lots of active users might have millions. Not having > looked at where they come from, maybe that isn't the case, but it > *might* be. > > Maybe adding something like a > > static int warn_every_1k = 0; > WARN_ON(size < 32 && (1023 & ++warn_every_1k)); > > to kmalloc() would give us a statistical view of "lots of these small > allocations" thing, and we could add GFP_NODMA to them. There probably > aren't that many places that have those small allocations, and it's > certainly safer to annotate "this is not for DMA" than have the > requirement that all DMA allocations must be marked. > > Then just teach kmalloc() something like > > align = (gfp_flags & __GFP_NODMA) ? 8 : 128; > > on arm. > Sounds like a lot of churn as well, tbh. But perhaps there are a few hot spots that we can fix that would alleviate the bulk of the issue, who knows? _______________________________________________ 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-15 6:04 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 [this message] 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 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=CAMj1kXGA4NH-Kg6rWRq2kUAsefwrOGUqTp47aFQTeaQoSB_1Cg@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.