* Re: [PATCH v4 1/2] xor: use kmalloc() in calibrate_xor_blocks()
From: Hannes Reinecke @ 2026-05-28 9:55 UTC (permalink / raw)
To: Mike Rapoport (Microsoft), Andrew Morton
Cc: Christoph Hellwig, David Laight, Li Nan, Song Liu, Xiao Ni,
Yu Kuai, linux-kernel, linux-mm, linux-raid
In-Reply-To: <20260528-lib-v4-1-4e3ad1277279@kernel.org>
On 5/28/26 11:53, Mike Rapoport (Microsoft) wrote:
> The xor benchmark allocates 4 pages for a scratch buffer that is used
> purely as a CPU-only XOR working area.
>
> This buffer can be allocated with kmalloc() as there's nothing special
> about it to go directly to the page allocator.
>
> kmalloc() provides a better API than ancient __get_free_pages().
> kmalloc() does not require ugly casts and kfree() does not need to know the
> size of the freed object.
>
> There is no performance difference because kmalloc() redirects allocations
> of such size to the page allocator.
>
> Replace __get_free_pages() call with kmalloc().
>
> Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
> lib/raid/xor/xor-core.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
Reviewed-by: Hannes Reinecke <hare@kernel.org>
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
^ permalink raw reply
* [PATCH v4 2/2] raid6: use kmalloc() in raid6_select_algo()
From: Mike Rapoport (Microsoft) @ 2026-05-28 9:53 UTC (permalink / raw)
To: Andrew Morton
Cc: Christoph Hellwig, David Laight, Li Nan, Mike Rapoport, Song Liu,
Xiao Ni, Yu Kuai, linux-kernel, linux-mm, linux-raid,
Christoph Hellwig
In-Reply-To: <20260528-lib-v4-0-4e3ad1277279@kernel.org>
raid6_select_algo() allocates 8 pages for buffer that is used
as a scratch area for selection of the best algorithm.
This buffer can be allocated with kmalloc() as there's nothing special
about it to go directly to the page allocator.
kmalloc() provides a better API than ancient __get_free_pages().
kmalloc() does not require ugly casts and kfree() does not need to know the
size of the freed object.
There is no performance difference because kmalloc() redirects allocations
of such size to the page allocator.
Replace __get_free_pages() call with kmalloc().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
lib/raid6/algos.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/raid6/algos.c b/lib/raid6/algos.c
index 799e0e5eac26..89e627c62e30 100644
--- a/lib/raid6/algos.c
+++ b/lib/raid6/algos.c
@@ -12,6 +12,7 @@
*/
#include <linux/raid/pq.h>
+#include <linux/slab.h>
#ifndef __KERNEL__
#include <sys/mman.h>
#include <stdio.h>
@@ -129,7 +130,6 @@ const struct raid6_recov_calls *const raid6_recov_algos[] = {
#endif
#define RAID6_TEST_DISKS 8
-#define RAID6_TEST_DISKS_ORDER 3
static inline const struct raid6_recov_calls *raid6_choose_recov(void)
{
@@ -250,7 +250,7 @@ int __init raid6_select_algo(void)
int i, cycle;
/* prepare the buffer and fill it circularly with gfmul table */
- disk_ptr = (char *)__get_free_pages(GFP_KERNEL, RAID6_TEST_DISKS_ORDER);
+ disk_ptr = kmalloc(PAGE_SIZE * RAID6_TEST_DISKS, GFP_KERNEL);
if (!disk_ptr) {
pr_err("raid6: Yikes! No memory available.\n");
return -ENOMEM;
@@ -275,7 +275,7 @@ int __init raid6_select_algo(void)
/* select raid recover functions */
rec_best = raid6_choose_recov();
- free_pages((unsigned long)disk_ptr, RAID6_TEST_DISKS_ORDER);
+ kfree(disk_ptr);
return gen_best && rec_best ? 0 : -EINVAL;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v4 1/2] xor: use kmalloc() in calibrate_xor_blocks()
From: Mike Rapoport (Microsoft) @ 2026-05-28 9:53 UTC (permalink / raw)
To: Andrew Morton
Cc: Christoph Hellwig, David Laight, Li Nan, Mike Rapoport, Song Liu,
Xiao Ni, Yu Kuai, linux-kernel, linux-mm, linux-raid
In-Reply-To: <20260528-lib-v4-0-4e3ad1277279@kernel.org>
The xor benchmark allocates 4 pages for a scratch buffer that is used
purely as a CPU-only XOR working area.
This buffer can be allocated with kmalloc() as there's nothing special
about it to go directly to the page allocator.
kmalloc() provides a better API than ancient __get_free_pages().
kmalloc() does not require ugly casts and kfree() does not need to know the
size of the freed object.
There is no performance difference because kmalloc() redirects allocations
of such size to the page allocator.
Replace __get_free_pages() call with kmalloc().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
---
lib/raid/xor/xor-core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/raid/xor/xor-core.c b/lib/raid/xor/xor-core.c
index bd4e6e434418..50931fbf0324 100644
--- a/lib/raid/xor/xor-core.c
+++ b/lib/raid/xor/xor-core.c
@@ -8,6 +8,7 @@
#include <linux/module.h>
#include <linux/gfp.h>
+#include <linux/slab.h>
#include <linux/raid/xor.h>
#include <linux/jiffies.h>
#include <linux/preempt.h>
@@ -114,7 +115,7 @@ static int __init calibrate_xor_blocks(void)
if (forced_template)
return 0;
- b1 = (void *) __get_free_pages(GFP_KERNEL, 2);
+ b1 = kmalloc(PAGE_SIZE * 4, GFP_KERNEL);
if (!b1) {
pr_warn("xor: Yikes! No memory available.\n");
return -ENOMEM;
@@ -132,7 +133,7 @@ static int __init calibrate_xor_blocks(void)
pr_info("xor: using function: %s (%d MB/sec)\n",
fastest->name, fastest->speed);
- free_pages((unsigned long)b1, 2);
+ kfree(b1);
return 0;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v4 0/2] lib/raid: replace __get_free_pages() call with kvmalloc()
From: Mike Rapoport (Microsoft) @ 2026-05-28 9:52 UTC (permalink / raw)
To: Andrew Morton
Cc: Christoph Hellwig, David Laight, Li Nan, Mike Rapoport, Song Liu,
Xiao Ni, Yu Kuai, linux-kernel, linux-mm, linux-raid,
Christoph Hellwig
This is a (tiny) part of larger work of replacing page allocator calls
with k*malloc.
Nowadays the right way to say "I need a buffer" is kmalloc() rather than
ancient and ugly __get_free_pages().
---
v4 changes:
* s/kvfee/kfree
v3: https://patch.msgid.link/20260528-lib-v3-0-feccddf1cb6d@kernel.org
* restore kmalloc() per Christoph
* update changelog
v2: https://patch.msgid.link/20260526-lib-v2-0-ca3f0fc24b14@kernel.org
* replace kmalloc() with kvmalloc()
v1: https://patch.msgid.link/20260520-lib-v1-0-cb3045bef2d8@kernel.org
---
Mike Rapoport (Microsoft) (2):
xor: use kmalloc() in calibrate_xor_blocks()
raid6: use kmalloc() in raid6_select_algo()
lib/raid/xor/xor-core.c | 5 +++--
lib/raid6/algos.c | 6 +++---
2 files changed, 6 insertions(+), 5 deletions(-)
---
base-commit: 5d6919055dec134de3c40167a490f33c74c12581
change-id: 20260520-lib-8afb92134307
Best regards,
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v3 1/2] xor: use kmalloc() in calibrate_xor_blocks()
From: Mike Rapoport @ 2026-05-28 9:49 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Andrew Morton, David Laight, Li Nan, Song Liu, Xiao Ni, Yu Kuai,
linux-kernel, linux-mm, linux-raid
In-Reply-To: <ahgC1PDFtFrJrsKC@infradead.org>
On Thu, May 28, 2026 at 01:54:44AM -0700, Christoph Hellwig wrote:
> On Thu, May 28, 2026 at 10:27:55AM +0300, Mike Rapoport (Microsoft) wrote:
> > - b1 = (void *) __get_free_pages(GFP_KERNEL, 2);
> > + b1 = kmalloc(PAGE_SIZE * 4, GFP_KERNEL);
> > if (!b1) {
> > pr_warn("xor: Yikes! No memory available.\n");
> > return -ENOMEM;
> > @@ -132,7 +133,7 @@ static int __init calibrate_xor_blocks(void)
> > pr_info("xor: using function: %s (%d MB/sec)\n",
> > fastest->name, fastest->speed);
> >
> > - free_pages((unsigned long)b1, 2);
> > + kvfree(b1);
>
> This should be kfree now.
kvfree still works, but I'll send v4 for pedantry sake ;-P
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v3 2/2] raid6: use kmalloc() in raid6_select_algo()
From: Christoph Hellwig @ 2026-05-28 8:55 UTC (permalink / raw)
To: Mike Rapoport (Microsoft)
Cc: Andrew Morton, Christoph Hellwig, David Laight, Li Nan, Song Liu,
Xiao Ni, Yu Kuai, linux-kernel, linux-mm, linux-raid
In-Reply-To: <20260528-lib-v3-2-feccddf1cb6d@kernel.org>
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH v3 1/2] xor: use kmalloc() in calibrate_xor_blocks()
From: Christoph Hellwig @ 2026-05-28 8:54 UTC (permalink / raw)
To: Mike Rapoport (Microsoft)
Cc: Andrew Morton, Christoph Hellwig, David Laight, Li Nan, Song Liu,
Xiao Ni, Yu Kuai, linux-kernel, linux-mm, linux-raid
In-Reply-To: <20260528-lib-v3-1-feccddf1cb6d@kernel.org>
On Thu, May 28, 2026 at 10:27:55AM +0300, Mike Rapoport (Microsoft) wrote:
> - b1 = (void *) __get_free_pages(GFP_KERNEL, 2);
> + b1 = kmalloc(PAGE_SIZE * 4, GFP_KERNEL);
> if (!b1) {
> pr_warn("xor: Yikes! No memory available.\n");
> return -ENOMEM;
> @@ -132,7 +133,7 @@ static int __init calibrate_xor_blocks(void)
> pr_info("xor: using function: %s (%d MB/sec)\n",
> fastest->name, fastest->speed);
>
> - free_pages((unsigned long)b1, 2);
> + kvfree(b1);
This should be kfree now.
^ permalink raw reply
* [PATCH v3 2/2] raid6: use kmalloc() in raid6_select_algo()
From: Mike Rapoport (Microsoft) @ 2026-05-28 7:27 UTC (permalink / raw)
To: Andrew Morton
Cc: Christoph Hellwig, David Laight, Li Nan, Mike Rapoport, Song Liu,
Xiao Ni, Yu Kuai, linux-kernel, linux-mm, linux-raid
In-Reply-To: <20260528-lib-v3-0-feccddf1cb6d@kernel.org>
raid6_select_algo() allocates 8 pages for buffer that is used
as a scratch area for selection of the best algorithm.
This buffer can be allocated with kmalloc() as there's nothing special
about it to go directly to the page allocator.
kmalloc() provides a better API than ancient __get_free_pages().
kmalloc() does not require ugly casts and kfree() does not need to know the
size of the freed object.
There is no performance difference because kmalloc() redirects allocations
of such size to the page allocator.
Replace __get_free_pages() call with kmalloc().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
---
lib/raid6/algos.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/raid6/algos.c b/lib/raid6/algos.c
index 799e0e5eac26..89e627c62e30 100644
--- a/lib/raid6/algos.c
+++ b/lib/raid6/algos.c
@@ -12,6 +12,7 @@
*/
#include <linux/raid/pq.h>
+#include <linux/slab.h>
#ifndef __KERNEL__
#include <sys/mman.h>
#include <stdio.h>
@@ -129,7 +130,6 @@ const struct raid6_recov_calls *const raid6_recov_algos[] = {
#endif
#define RAID6_TEST_DISKS 8
-#define RAID6_TEST_DISKS_ORDER 3
static inline const struct raid6_recov_calls *raid6_choose_recov(void)
{
@@ -250,7 +250,7 @@ int __init raid6_select_algo(void)
int i, cycle;
/* prepare the buffer and fill it circularly with gfmul table */
- disk_ptr = (char *)__get_free_pages(GFP_KERNEL, RAID6_TEST_DISKS_ORDER);
+ disk_ptr = kmalloc(PAGE_SIZE * RAID6_TEST_DISKS, GFP_KERNEL);
if (!disk_ptr) {
pr_err("raid6: Yikes! No memory available.\n");
return -ENOMEM;
@@ -275,7 +275,7 @@ int __init raid6_select_algo(void)
/* select raid recover functions */
rec_best = raid6_choose_recov();
- free_pages((unsigned long)disk_ptr, RAID6_TEST_DISKS_ORDER);
+ kfree(disk_ptr);
return gen_best && rec_best ? 0 : -EINVAL;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v3 1/2] xor: use kmalloc() in calibrate_xor_blocks()
From: Mike Rapoport (Microsoft) @ 2026-05-28 7:27 UTC (permalink / raw)
To: Andrew Morton
Cc: Christoph Hellwig, David Laight, Li Nan, Mike Rapoport, Song Liu,
Xiao Ni, Yu Kuai, linux-kernel, linux-mm, linux-raid
In-Reply-To: <20260528-lib-v3-0-feccddf1cb6d@kernel.org>
The xor benchmark allocates 4 pages for a scratch buffer that is used
purely as a CPU-only XOR working area.
This buffer can be allocated with kmalloc() as there's nothing special
about it to go directly to the page allocator.
kmalloc() provides a better API than ancient __get_free_pages().
kmalloc() does not require ugly casts and kfree() does not need to know the
size of the freed object.
There is no performance difference because kmalloc() redirects allocations
of such size to the page allocator.
Replace __get_free_pages() call with kmalloc().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
---
lib/raid/xor/xor-core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/raid/xor/xor-core.c b/lib/raid/xor/xor-core.c
index bd4e6e434418..7f6436774644 100644
--- a/lib/raid/xor/xor-core.c
+++ b/lib/raid/xor/xor-core.c
@@ -8,6 +8,7 @@
#include <linux/module.h>
#include <linux/gfp.h>
+#include <linux/slab.h>
#include <linux/raid/xor.h>
#include <linux/jiffies.h>
#include <linux/preempt.h>
@@ -114,7 +115,7 @@ static int __init calibrate_xor_blocks(void)
if (forced_template)
return 0;
- b1 = (void *) __get_free_pages(GFP_KERNEL, 2);
+ b1 = kmalloc(PAGE_SIZE * 4, GFP_KERNEL);
if (!b1) {
pr_warn("xor: Yikes! No memory available.\n");
return -ENOMEM;
@@ -132,7 +133,7 @@ static int __init calibrate_xor_blocks(void)
pr_info("xor: using function: %s (%d MB/sec)\n",
fastest->name, fastest->speed);
- free_pages((unsigned long)b1, 2);
+ kvfree(b1);
return 0;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v3 0/2] lib/raid: replace __get_free_pages() call with kvmalloc()
From: Mike Rapoport (Microsoft) @ 2026-05-28 7:27 UTC (permalink / raw)
To: Andrew Morton
Cc: Christoph Hellwig, David Laight, Li Nan, Mike Rapoport, Song Liu,
Xiao Ni, Yu Kuai, linux-kernel, linux-mm, linux-raid
This is a (tiny) part of larger work of replacing page allocator calls
with k*malloc.
Nowadays the right way to say "I need a buffer" is kmalloc() rather than
ancient and ugly __get_free_pages().
---
v3 changes:
* restore kmalloc() per Christoph
* update changelog
v2: https://patch.msgid.link/20260526-lib-v2-0-ca3f0fc24b14@kernel.org
* replace kmalloc() with kvmalloc()
v1: https://patch.msgid.link/20260520-lib-v1-0-cb3045bef2d8@kernel.org
---
Mike Rapoport (Microsoft) (2):
xor: use kmalloc() in calibrate_xor_blocks()
raid6: use kmalloc() in raid6_select_algo()
lib/raid/xor/xor-core.c | 5 +++--
lib/raid6/algos.c | 6 +++---
2 files changed, 6 insertions(+), 5 deletions(-)
---
base-commit: 5d6919055dec134de3c40167a490f33c74c12581
change-id: 20260520-lib-8afb92134307
Best regards,
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH 7/8] lib/raid6: Include asm/neon-intrinsics.h rather than arm_neon.h
From: Ard Biesheuvel @ 2026-05-27 15:42 UTC (permalink / raw)
To: Eric Biggers, Christoph Hellwig
Cc: Ard Biesheuvel, linux-arm-kernel, linux-crypto, linux-raid,
Russell King, Arnd Bergmann
In-Reply-To: <20260527015754.GA13078@sol>
On Wed, 27 May 2026, at 03:57, Eric Biggers wrote:
> On Sat, May 09, 2026 at 01:23:54PM -0700, Eric Biggers wrote:
>> On Thu, Apr 23, 2026 at 09:47:12AM +0200, Christoph Hellwig wrote:
>> > On Wed, Apr 22, 2026 at 07:17:03PM +0200, Ard Biesheuvel wrote:
>> > > From: Ard Biesheuvel <ardb@kernel.org>
>> > >
>> > > arm_neon.h is a compiler header which needs some scaffolding to work
>> > > correctly in the linux context, and so it is better not to include it
>> > > directly. Both ARM and arm64 now provide asm/neon-intrinsics.h which
>> > > takes care of this.
>> >
>> >
>> > This could potentially clash with the raid6 library rework I'm doing
>> > for 7.2. Although git has become pretty good about renamed files, so
>> > maybe it won't be so bad.
>> >
>>
>> I think this patch also breaks the userspace build of lib/raid6/. Which
>> is going away in Christoph's series anyway, but maybe it would make
>> sense to drop this patch (and patch 8 which depends on this, I think)
>> from this series for now? That would make it a bit easier to take the
>> rest through crc-next.
>
> Ard, are you okay with me applying just patches 1-6 to crc-next?
Yes that's fine - thanks.
^ permalink raw reply
* [PATCH] md/raid0: use str_plural helper in dump_zones
From: Thorsten Blum @ 2026-05-27 14:19 UTC (permalink / raw)
To: Song Liu, Yu Kuai, Li Nan, Xiao Ni
Cc: Thorsten Blum, linux-raid, linux-kernel
Replace the manual ternary "s" pluralization with str_plural() to
simplify the code.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/md/raid0.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c
index 5e38a51e349a..699c2de8983a 100644
--- a/drivers/md/raid0.c
+++ b/drivers/md/raid0.c
@@ -14,6 +14,7 @@
#include <linux/seq_file.h>
#include <linux/module.h>
#include <linux/slab.h>
+#include <linux/string_choices.h>
#include <trace/events/block.h>
#include "md.h"
#include "raid0.h"
@@ -43,7 +44,7 @@ static void dump_zones(struct mddev *mddev)
int raid_disks = conf->strip_zone[0].nb_dev;
pr_debug("md: RAID0 configuration for %s - %d zone%s\n",
mdname(mddev),
- conf->nr_strip_zones, conf->nr_strip_zones==1?"":"s");
+ conf->nr_strip_zones, str_plural(conf->nr_strip_zones));
for (j = 0; j < conf->nr_strip_zones; j++) {
char line[200];
int len = 0;
^ permalink raw reply related
* Re: [PATCH v2 2/2] lib/raid6: use kvmalloc() in raid6_select_algo()
From: Mike Rapoport @ 2026-05-27 11:28 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Andrew Morton, Song Liu, Yu Kuai, Li Nan, Xiao Ni, David Laight,
linux-kernel, linux-mm, linux-raid
In-Reply-To: <20260527063814.GA17042@lst.de>
On Wed, May 27, 2026 at 08:38:14AM +0200, Christoph Hellwig wrote:
> On Tue, May 26, 2026 at 10:34:24AM -0700, Andrew Morton wrote:
> > /* prepare the buffer and fill it circularly with gfmul table */
> > - disk_ptr = (char *)__get_free_pages(GFP_KERNEL, RAID6_TEST_DISKS_ORDER);
> > + disk_ptr = kvmalloc(PAGE_SIZE * RAID6_TEST_DISKS, GFP_KERNEL);
>
> This changes to vmalloc for no good reason. It also doesn't use
TBH, I didn't look around and just presumed that order-3 allocation is a
good candidate for vmalloc().
But given this runs early on boot, there's no real reason for vmalloc().
> the _array version for overflow-safe multiplying (not that it matters
> much here..)
Can do _array if you'd like, no strong feelings here.
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH 2/2] lib/raid6: use kmalloc() in raid6_select_algo()
From: Mike Rapoport @ 2026-05-27 11:12 UTC (permalink / raw)
To: David Laight
Cc: Song Liu, Yu Kuai, Li Nan, Xiao Ni, linux-kernel, linux-mm,
linux-raid
In-Reply-To: <20260527093720.1261e697@pumpkin>
On Wed, May 27, 2026 at 09:37:20AM +0100, David Laight wrote:
> On Tue, 26 May 2026 17:38:24 +0300
> Mike Rapoport <rppt@kernel.org> wrote:
>
> > On Wed, May 20, 2026 at 02:06:57PM +0100, David Laight wrote:
> > > On Wed, 20 May 2026 11:17:52 +0300
> > > "Mike Rapoport (Microsoft)" <rppt@kernel.org> wrote:
> > >
> > > > raid6_select_algo() allocates an order 3 (8 pages) buffer that is used
> > > > as a scratch area for selection of the best algorithm.
> > >
> > > Should this code really be using a 4k buffer rather than a PAGE_SIZE one?
> >
> > Why?
>
> Why a PAGE_SIZE buffer at all?
> The real data will either be file-system block/fragment or raid stripe sized.
> Neither is directly related to the memory system page size.
>
> This actually a valid question for pretty much all of these changes.
>
> Most architectures use 4k pages (probably because 3-level page tables
> fit nicely into a 32bit word and it gave a reasonable number of pages
> for 1980s systems) but some use much larger pages; I think 64k and 256k
> both get used.
> (IIRC m68k hardware uses 2k pages, but Linux uses them in pairs.)
> Larger pages reduce allocation costs, TLB pressure and memory overhead.
> But can waste memory especially for mmap() of small files.
>
> Most of these functions just want 'a reasonable sized buffer'.
> Possibly requesting whole pages was originally cheaper.
> But I also suspect people have written PAGE_SIZE as a name for 4096.
> (Much the same as they forget that some systems have 256 byte cache lines.)
>
> For these changes I think I'd at least add a note in the commit message
> when nothing external relies in the size of the buffer and that it could
> be changed to 4k.
The changes from gfp to kmalloc are intentionally mechanical and
intentionally keep the same allocation size.
The point of these changes is to stop using ancient and ugly gfp and change
users that need a buffer to use kmalloc().
It will also make it easier to differentiate uses that actually need the
*page* for the folio project.
What is the actual buffer size required is a completely different audit and
it's not related to API usage change.
> -- David
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH 2/2] lib/raid6: use kmalloc() in raid6_select_algo()
From: David Laight @ 2026-05-27 8:37 UTC (permalink / raw)
To: Mike Rapoport
Cc: Song Liu, Yu Kuai, Li Nan, Xiao Ni, linux-kernel, linux-mm,
linux-raid
In-Reply-To: <ahWwYIOycuWZnETn@kernel.org>
On Tue, 26 May 2026 17:38:24 +0300
Mike Rapoport <rppt@kernel.org> wrote:
> On Wed, May 20, 2026 at 02:06:57PM +0100, David Laight wrote:
> > On Wed, 20 May 2026 11:17:52 +0300
> > "Mike Rapoport (Microsoft)" <rppt@kernel.org> wrote:
> >
> > > raid6_select_algo() allocates an order 3 (8 pages) buffer that is used
> > > as a scratch area for selection of the best algorithm.
> >
> > Should this code really be using a 4k buffer rather than a PAGE_SIZE one?
>
> Why?
Why a PAGE_SIZE buffer at all?
The real data will either be file-system block/fragment or raid stripe sized.
Neither is directly related to the memory system page size.
This actually a valid question for pretty much all of these changes.
Most architectures use 4k pages (probably because 3-level page tables
fit nicely into a 32bit word and it gave a reasonable number of pages
for 1980s systems) but some use much larger pages; I think 64k and 256k
both get used.
(IIRC m68k hardware uses 2k pages, but Linux uses them in pairs.)
Larger pages reduce allocation costs, TLB pressure and memory overhead.
But can waste memory especially for mmap() of small files.
Most of these functions just want 'a reasonable sized buffer'.
Possibly requesting whole pages was originally cheaper.
But I also suspect people have written PAGE_SIZE as a name for 4096.
(Much the same as they forget that some systems have 256 byte cache lines.)
For these changes I think I'd at least add a note in the commit message
when nothing external relies in the size of the buffer and that it could
be changed to 4k.
-- David
>
> > -- David
> >
> > >
> > > For such large allocations kmalloc() would fall back to alloc_pages() but
> > > still kmalloc() is a better API as it does not require unnecessary
> > > castings and may provide more debugging possibilities.
> > >
> > > Replace __get_free_pages() call with kmalloc().
> > >
> > > Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
> > > Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> > > ---
> > > lib/raid6/algos.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/lib/raid6/algos.c b/lib/raid6/algos.c
> > > index 799e0e5eac26..89e627c62e30 100644
> > > --- a/lib/raid6/algos.c
> > > +++ b/lib/raid6/algos.c
> > > @@ -12,6 +12,7 @@
> > > */
> > >
> > > #include <linux/raid/pq.h>
> > > +#include <linux/slab.h>
> > > #ifndef __KERNEL__
> > > #include <sys/mman.h>
> > > #include <stdio.h>
> > > @@ -129,7 +130,6 @@ const struct raid6_recov_calls *const raid6_recov_algos[] = {
> > > #endif
> > >
> > > #define RAID6_TEST_DISKS 8
> > > -#define RAID6_TEST_DISKS_ORDER 3
> > >
> > > static inline const struct raid6_recov_calls *raid6_choose_recov(void)
> > > {
> > > @@ -250,7 +250,7 @@ int __init raid6_select_algo(void)
> > > int i, cycle;
> > >
> > > /* prepare the buffer and fill it circularly with gfmul table */
> > > - disk_ptr = (char *)__get_free_pages(GFP_KERNEL, RAID6_TEST_DISKS_ORDER);
> > > + disk_ptr = kmalloc(PAGE_SIZE * RAID6_TEST_DISKS, GFP_KERNEL);
> > > if (!disk_ptr) {
> > > pr_err("raid6: Yikes! No memory available.\n");
> > > return -ENOMEM;
> > > @@ -275,7 +275,7 @@ int __init raid6_select_algo(void)
> > > /* select raid recover functions */
> > > rec_best = raid6_choose_recov();
> > >
> > > - free_pages((unsigned long)disk_ptr, RAID6_TEST_DISKS_ORDER);
> > > + kfree(disk_ptr);
> > >
> > > return gen_best && rec_best ? 0 : -EINVAL;
> > > }
> > >
> >
> >
>
^ permalink raw reply
* [PATCH 2/2] raid6/x86: register avx512 after avx2
From: Christoph Hellwig @ 2026-05-27 7:45 UTC (permalink / raw)
To: Andrew Morton; +Cc: Song Liu, Yu Kuai, Li Nan, Xiao Ni, linux-raid
In-Reply-To: <20260527074539.2292913-1-hch@lst.de>
This way non-benchmarks configs still get avx512 if supported.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
lib/raid/raid6/x86/pq_arch.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/raid/raid6/x86/pq_arch.h b/lib/raid/raid6/x86/pq_arch.h
index 28e395eb04d1..02f8843b0537 100644
--- a/lib/raid/raid6/x86/pq_arch.h
+++ b/lib/raid/raid6/x86/pq_arch.h
@@ -60,16 +60,16 @@ static inline bool raid6_has_sse1_or_mmxext(void)
static __always_inline void __init arch_raid6_init(void)
{
if (raid6_has_avx2()) {
+ raid6_algo_add(&raid6_avx2x1);
+ raid6_algo_add(&raid6_avx2x2);
+ if (IS_ENABLED(CONFIG_X86_64))
+ raid6_algo_add(&raid6_avx2x4);
if (raid6_has_avx512()) {
raid6_algo_add(&raid6_avx512x1);
raid6_algo_add(&raid6_avx512x2);
if (IS_ENABLED(CONFIG_X86_64))
raid6_algo_add(&raid6_avx512x4);
}
- raid6_algo_add(&raid6_avx2x1);
- raid6_algo_add(&raid6_avx2x2);
- if (IS_ENABLED(CONFIG_X86_64))
- raid6_algo_add(&raid6_avx2x4);
} else if (IS_ENABLED(CONFIG_X86_64) || raid6_has_sse2()) {
/* x86_64 can assume SSE2 as baseline */
raid6_algo_add(&raid6_sse2x1);
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] raid6: remove duplicate ccflags-y line
From: Christoph Hellwig @ 2026-05-27 7:45 UTC (permalink / raw)
To: Andrew Morton; +Cc: Song Liu, Yu Kuai, Li Nan, Xiao Ni, linux-raid
In-Reply-To: <20260527074539.2292913-1-hch@lst.de>
This was added by a mismerge when rebasing, remove it.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
lib/raid/raid6/Makefile | 2 --
1 file changed, 2 deletions(-)
diff --git a/lib/raid/raid6/Makefile b/lib/raid/raid6/Makefile
index 1d79b76b320e..038d6c74d1ba 100644
--- a/lib/raid/raid6/Makefile
+++ b/lib/raid/raid6/Makefile
@@ -2,8 +2,6 @@
ccflags-y += -I $(src)
-ccflags-y += -I $(src)
-
ifeq ($(CONFIG_RAID6_PQ_ARCH),y)
CFLAGS_algos.o += -I$(src)/$(SRCARCH)
endif
--
2.53.0
^ permalink raw reply related
* incremental fixes for "cleanup the RAID6 P/Q library v3"
From: Christoph Hellwig @ 2026-05-27 7:45 UTC (permalink / raw)
To: Andrew Morton; +Cc: Song Liu, Yu Kuai, Li Nan, Xiao Ni, linux-raid
Hi Andrew,
here are two incremental fixes for above series. They could be folded
into "raid6: hide internals" and "raid6: rework registration of optimized
algorithms" respectively if desired.
Diffstat:
Makefile | 2 --
x86/pq_arch.h | 8 ++++----
2 files changed, 4 insertions(+), 6 deletions(-)
^ permalink raw reply
* Re: [PATCH v2 2/2] lib/raid6: use kvmalloc() in raid6_select_algo()
From: Christoph Hellwig @ 2026-05-27 7:33 UTC (permalink / raw)
To: Mike Rapoport (Microsoft)
Cc: Andrew Morton, Song Liu, Yu Kuai, Li Nan, Xiao Ni, David Laight,
linux-kernel, linux-mm, linux-raid
In-Reply-To: <20260526-lib-v2-2-ca3f0fc24b14@kernel.org>
Please stick to the raid6: prefix used for all commits since the move
and most before that.
^ permalink raw reply
* Re: [PATCH v2 1/2] lib/raid: use kvmalloc() in calibrate_xor_blocks()
From: Christoph Hellwig @ 2026-05-27 7:32 UTC (permalink / raw)
To: Mike Rapoport (Microsoft)
Cc: Andrew Morton, Song Liu, Yu Kuai, Li Nan, Xiao Ni, David Laight,
linux-kernel, linux-mm, linux-raid
In-Reply-To: <20260526-lib-v2-1-ca3f0fc24b14@kernel.org>
Can you stick to the xor: prefix used for all commits since moving it
to lib?
^ permalink raw reply
* Re: [PATCH v2 2/2] lib/raid6: use kvmalloc() in raid6_select_algo()
From: Christoph Hellwig @ 2026-05-27 6:38 UTC (permalink / raw)
To: Andrew Morton
Cc: Mike Rapoport (Microsoft), Song Liu, Yu Kuai, Li Nan, Xiao Ni,
David Laight, linux-kernel, linux-mm, linux-raid,
Christoph Hellwig
In-Reply-To: <20260526103424.0d884374dee8cbc4f9f17c3a@linux-foundation.org>
On Tue, May 26, 2026 at 10:34:24AM -0700, Andrew Morton wrote:
> /* prepare the buffer and fill it circularly with gfmul table */
> - disk_ptr = (char *)__get_free_pages(GFP_KERNEL, RAID6_TEST_DISKS_ORDER);
> + disk_ptr = kvmalloc(PAGE_SIZE * RAID6_TEST_DISKS, GFP_KERNEL);
This changes to vmalloc for no good reason. It also doesn't use
the _array version for overflow-safe multiplying (not that it matters
much here..)
^ permalink raw reply
* Re: [PATCH V4 0/3] md/nvme: Enable PCI P2PDMA support for RAID0 and NVMe Multipath
From: Chaitanya Kulkarni @ 2026-05-27 4:03 UTC (permalink / raw)
To: Jens Axboe
Cc: song@kernel.org, yukuai@fnnas.com, Christoph Hellwig,
linan122@huawei.com, kbusch@kernel.org, sagi@grimberg.me,
linux-block@vger.kernel.org, linux-raid@vger.kernel.org,
linux-nvme@lists.infradead.org, Kiran Modukuri
In-Reply-To: <b89e372e-3068-4c26-9552-13e6853ba000@kernel.dk>
On 5/26/26 14:51, Jens Axboe wrote:
>> There is outstanding work I want to send out based on this one.
> Out standing, outstanding, or both? 🙂
just few fixes :)
>> May I please request you to merge this patch series ?
> Was waiting on the md parts to get reviewed, by I missed that Xiao Ni
> already did. I'll queue it up.
>
> -- Jens Axboe
Thanks a lot.
-ck
^ permalink raw reply
* Re: [PATCH 7/8] lib/raid6: Include asm/neon-intrinsics.h rather than arm_neon.h
From: Eric Biggers @ 2026-05-27 1:57 UTC (permalink / raw)
To: Christoph Hellwig, Ard Biesheuvel
Cc: Ard Biesheuvel, linux-arm-kernel, linux-crypto, linux-raid,
Ard Biesheuvel, Russell King, Arnd Bergmann
In-Reply-To: <20260509202354.GD11883@quark>
On Sat, May 09, 2026 at 01:23:54PM -0700, Eric Biggers wrote:
> On Thu, Apr 23, 2026 at 09:47:12AM +0200, Christoph Hellwig wrote:
> > On Wed, Apr 22, 2026 at 07:17:03PM +0200, Ard Biesheuvel wrote:
> > > From: Ard Biesheuvel <ardb@kernel.org>
> > >
> > > arm_neon.h is a compiler header which needs some scaffolding to work
> > > correctly in the linux context, and so it is better not to include it
> > > directly. Both ARM and arm64 now provide asm/neon-intrinsics.h which
> > > takes care of this.
> >
> >
> > This could potentially clash with the raid6 library rework I'm doing
> > for 7.2. Although git has become pretty good about renamed files, so
> > maybe it won't be so bad.
> >
>
> I think this patch also breaks the userspace build of lib/raid6/. Which
> is going away in Christoph's series anyway, but maybe it would make
> sense to drop this patch (and patch 8 which depends on this, I think)
> from this series for now? That would make it a bit easier to take the
> rest through crc-next.
Ard, are you okay with me applying just patches 1-6 to crc-next?
- Eric
^ permalink raw reply
* Re: [PATCH V4 0/3] md/nvme: Enable PCI P2PDMA support for RAID0 and NVMe Multipath
From: Jens Axboe @ 2026-05-26 21:52 UTC (permalink / raw)
To: song, yukuai, linan122, kbusch, hch, sagi, Chaitanya Kulkarni
Cc: linux-block, linux-raid, linux-nvme, kmodukuri
In-Reply-To: <20260513185153.95552-1-kch@nvidia.com>
On Wed, 13 May 2026 11:51:50 -0700, Chaitanya Kulkarni wrote:
> This patch series extends PCI peer-to-peer DMA (P2PDMA) support to enable
> direct data transfers between PCIe devices through RAID and NVMe multipath
> block layers.
>
> Current Linux kernel P2PDMA infrastructure supports direct peer-to-peer
> transfers, but this support is not propagated through certain storage
> stacks like MD RAID and NVMe multipath. This adds two patches for
> MD RAID 0/1/10 and NVMe to propogate P2PDMA support through the
> storage stack.
>
> [...]
Applied, thanks!
[1/3] block: clear BLK_FEAT_PCI_P2PDMA in blk_stack_limits() for non-supporting devices
commit: 7882834048f110931275357db60dccff906dc96a
[2/3] md: propagate BLK_FEAT_PCI_P2PDMA from member devices to RAID device
commit: 02666132403aec8fc5de315002894f713ef17dbc
[3/3] nvme-multipath: enable PCI P2PDMA for multipath devices
commit: fb0eeeed91f3236133383445fee5cc8f20330e6e
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH V4 0/3] md/nvme: Enable PCI P2PDMA support for RAID0 and NVMe Multipath
From: Jens Axboe @ 2026-05-26 21:51 UTC (permalink / raw)
To: Chaitanya Kulkarni
Cc: song@kernel.org, yukuai@fnnas.com, Christoph Hellwig,
linan122@huawei.com, kbusch@kernel.org, sagi@grimberg.me,
linux-block@vger.kernel.org, linux-raid@vger.kernel.org,
linux-nvme@lists.infradead.org, Kiran Modukuri
In-Reply-To: <053b99b2-c994-42ff-af63-6e63ab468557@nvidia.com>
On 5/26/26 11:09 AM, Chaitanya Kulkarni wrote:
> Jens,
>
> On 5/19/26 17:11, Chaitanya Kulkarni wrote:
>> Jens,
>>
>>
>> On 5/14/26 9:35 PM, Christoph Hellwig wrote:
>>> Still looks good to me as per the reviews.
>>>
>> If there no objection, can we merge this ?
>>
>> -Chaitanya
>>
>>
> There is outstanding work I want to send out based on this one.
Out standing, outstanding, or both? :-)
> May I please request you to merge this patch series ?
Was waiting on the md parts to get reviewed, by I missed that Xiao Ni
already did. I'll queue it up.
--
Jens Axboe
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox