[PATCH 15/14] arm: Rename PMD_ORDER to PMD_BITS

[PATCH 15/14] arm: Rename PMD_ORDER to PMD_BITS

[Matthew Wilcox (Oracle)]

This is the number of bits used by a PMD entry, not the order of a PMD.

Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
---
 arch/arm/kernel/head.S | 34 +++++++++++++++++-----------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 500612d3da2e..d16159ced58f 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -38,10 +38,10 @@
 #ifdef CONFIG_ARM_LPAE
 	/* LPAE requires an additional page for the PGD */
 #define PG_DIR_SIZE	0x5000
-#define PMD_ORDER	3
+#define PMD_BITS	3
 #else
 #define PG_DIR_SIZE	0x4000
-#define PMD_ORDER	2
+#define PMD_BITS	2
 #endif
 
 	.globl	swapper_pg_dir
@@ -240,7 +240,7 @@ __create_page_tables:
 	mov	r6, r6, lsr #SECTION_SHIFT
 
 1:	orr	r3, r7, r5, lsl #SECTION_SHIFT	@ flags + kernel base
-	str	r3, [r4, r5, lsl #PMD_ORDER]	@ identity mapping
+	str	r3, [r4, r5, lsl #PMD_BITS]	@ identity mapping
 	cmp	r5, r6
 	addlo	r5, r5, #1			@ next section
 	blo	1b
@@ -250,7 +250,7 @@ __create_page_tables:
 	 * set two variables to indicate the physical start and end of the
 	 * kernel.
 	 */
-	add	r0, r4, #KERNEL_OFFSET >> (SECTION_SHIFT - PMD_ORDER)
+	add	r0, r4, #KERNEL_OFFSET >> (SECTION_SHIFT - PMD_BITS)
 	ldr	r6, =(_end - 1)
 	adr_l	r5, kernel_sec_start		@ _pa(kernel_sec_start)
 #if defined CONFIG_CPU_ENDIAN_BE8 || defined CONFIG_CPU_ENDIAN_BE32
@@ -259,8 +259,8 @@ __create_page_tables:
 	str	r8, [r5]			@ Save physical start of kernel (LE)
 #endif
 	orr	r3, r8, r7			@ Add the MMU flags
-	add	r6, r4, r6, lsr #(SECTION_SHIFT - PMD_ORDER)
-1:	str	r3, [r0], #1 << PMD_ORDER
+	add	r6, r4, r6, lsr #(SECTION_SHIFT - PMD_BITS)
+1:	str	r3, [r0], #1 << PMD_BITS
 	add	r3, r3, #1 << SECTION_SHIFT
 	cmp	r0, r6
 	bls	1b
@@ -280,14 +280,14 @@ __create_page_tables:
 	mov	r3, pc
 	mov	r3, r3, lsr #SECTION_SHIFT
 	orr	r3, r7, r3, lsl #SECTION_SHIFT
-	add	r0, r4,  #(XIP_START & 0xff000000) >> (SECTION_SHIFT - PMD_ORDER)
-	str	r3, [r0, #((XIP_START & 0x00f00000) >> SECTION_SHIFT) << PMD_ORDER]!
+	add	r0, r4,  #(XIP_START & 0xff000000) >> (SECTION_SHIFT - PMD_BITS)
+	str	r3, [r0, #((XIP_START & 0x00f00000) >> SECTION_SHIFT) << PMD_BITS]!
 	ldr	r6, =(_edata_loc - 1)
-	add	r0, r0, #1 << PMD_ORDER
-	add	r6, r4, r6, lsr #(SECTION_SHIFT - PMD_ORDER)
+	add	r0, r0, #1 << PMD_BITS
+	add	r6, r4, r6, lsr #(SECTION_SHIFT - PMD_BITS)
 1:	cmp	r0, r6
 	add	r3, r3, #1 << SECTION_SHIFT
-	strls	r3, [r0], #1 << PMD_ORDER
+	strls	r3, [r0], #1 << PMD_BITS
 	bls	1b
 #endif
 
@@ -297,10 +297,10 @@ __create_page_tables:
 	 */
 	mov	r0, r2, lsr #SECTION_SHIFT
 	cmp	r2, #0
-	ldrne	r3, =FDT_FIXED_BASE >> (SECTION_SHIFT - PMD_ORDER)
+	ldrne	r3, =FDT_FIXED_BASE >> (SECTION_SHIFT - PMD_BITS)
 	addne	r3, r3, r4
 	orrne	r6, r7, r0, lsl #SECTION_SHIFT
-	strne	r6, [r3], #1 << PMD_ORDER
+	strne	r6, [r3], #1 << PMD_BITS
 	addne	r6, r6, #1 << SECTION_SHIFT
 	strne	r6, [r3]
 
@@ -319,7 +319,7 @@ __create_page_tables:
 	addruart r7, r3, r0
 
 	mov	r3, r3, lsr #SECTION_SHIFT
-	mov	r3, r3, lsl #PMD_ORDER
+	mov	r3, r3, lsl #PMD_BITS
 
 	add	r0, r4, r3
 	mov	r3, r7, lsr #SECTION_SHIFT
@@ -349,7 +349,7 @@ __create_page_tables:
 	 * If we're using the NetWinder or CATS, we also need to map
 	 * in the 16550-type serial port for the debug messages
 	 */
-	add	r0, r4, #0xff000000 >> (SECTION_SHIFT - PMD_ORDER)
+	add	r0, r4, #0xff000000 >> (SECTION_SHIFT - PMD_BITS)
 	orr	r3, r7, #0x7c000000
 	str	r3, [r0]
 #endif
@@ -359,10 +359,10 @@ __create_page_tables:
 	 * Similar reasons here - for debug.  This is
 	 * only for Acorn RiscPC architectures.
 	 */
-	add	r0, r4, #0x02000000 >> (SECTION_SHIFT - PMD_ORDER)
+	add	r0, r4, #0x02000000 >> (SECTION_SHIFT - PMD_BITS)
 	orr	r3, r7, #0x02000000
 	str	r3, [r0]
-	add	r0, r4, #0xd8000000 >> (SECTION_SHIFT - PMD_ORDER)
+	add	r0, r4, #0xd8000000 >> (SECTION_SHIFT - PMD_BITS)
 	str	r3, [r0]
 #endif
 #endif
-- 
2.35.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 15/14] arm: Rename PMD_ORDER to PMD_BITS

[Russell King (Oracle)]

On Sun, Jul 03, 2022 at 10:14:41PM +0100, Matthew Wilcox (Oracle) wrote:
> This is the number of bits used by a PMD entry, not the order of a PMD.

No, it's not the number of bits. A PMD entry doesn't fit in 2 or 3 bits.
This is even more confusing.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 15/14] arm: Rename PMD_ORDER to PMD_BITS

[Matthew Wilcox]

On Sun, Jul 03, 2022 at 10:16:45PM +0100, Russell King (Oracle) wrote:
> On Sun, Jul 03, 2022 at 10:14:41PM +0100, Matthew Wilcox (Oracle) wrote:
> > This is the number of bits used by a PMD entry, not the order of a PMD.
> 
> No, it's not the number of bits. A PMD entry doesn't fit in 2 or 3 bits.
> This is even more confusing.

Well, what is it then?  The order of something is PAGE_SIZE << n, and
that doesn't seem to be what this is.  Happy to call it whatever you
want to call it.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 15/14] arm: Rename PMD_ORDER to PMD_BITS

[Russell King (Oracle)]

On Sun, Jul 03, 2022 at 10:54:49PM +0100, Matthew Wilcox wrote:
> On Sun, Jul 03, 2022 at 10:16:45PM +0100, Russell King (Oracle) wrote:
> > On Sun, Jul 03, 2022 at 10:14:41PM +0100, Matthew Wilcox (Oracle) wrote:
> > > This is the number of bits used by a PMD entry, not the order of a PMD.
> > 
> > No, it's not the number of bits. A PMD entry doesn't fit in 2 or 3 bits.
> > This is even more confusing.
> 
> Well, what is it then?  The order of something is PAGE_SIZE << n, and
> that doesn't seem to be what this is.

Where is it defined that "order" means "PAGE_SIZE << n" ?

"order" here is "order of magnitude" and in this case, it is 2^n, just
like order of magnitude in base 10 is 10^n. So strictly, the usage
here is completely correct, but if you describe "order" as "PAGE_SIZE <<
n" that is no longer an order of magnitude, because it doesn't increase
in an order of magnitude (iow, n = 2 isn't PAGE_SIZE * PAGE_SIZE).

Now, if you're trying to tell me that Linux has decided to define
"order" to be something non-standard, I'll accept that, but then we
shouldn't be renaming stuff that is using it in a standard way.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 15/14] arm: Rename PMD_ORDER to PMD_BITS

[Mike Rapoport]

On Mon, Jul 04, 2022 at 05:32:33AM +0100, Russell King (Oracle) wrote:
> On Sun, Jul 03, 2022 at 10:54:49PM +0100, Matthew Wilcox wrote:
> > On Sun, Jul 03, 2022 at 10:16:45PM +0100, Russell King (Oracle) wrote:
> > > On Sun, Jul 03, 2022 at 10:14:41PM +0100, Matthew Wilcox (Oracle) wrote:
> > > > This is the number of bits used by a PMD entry, not the order of a PMD.
> > > 
> > > No, it's not the number of bits. A PMD entry doesn't fit in 2 or 3 bits.
> > > This is even more confusing.
> > 
> > Well, what is it then?  The order of something is PAGE_SIZE << n, and
> > that doesn't seem to be what this is.
> 
> Where is it defined that "order" means "PAGE_SIZE << n" ?
> 
> "order" here is "order of magnitude" and in this case, it is 2^n, just
> like order of magnitude in base 10 is 10^n. So strictly, the usage
> here is completely correct, but if you describe "order" as "PAGE_SIZE <<
> n" that is no longer an order of magnitude, because it doesn't increase
> in an order of magnitude (iow, n = 2 isn't PAGE_SIZE * PAGE_SIZE).

I'd go with PMD_ENTRY_ORDER as Russell suggested last year.

From 6389dfb2e5ae5b040ca1c8f07a071d8da2873b13 Mon Sep 17 00:00:00 2001
From: Mike Rapoport <rppt@linux.ibm.com>
Date: Mon, 4 Jul 2022 09:17:40 +0300
Subject: [PATCH] ARM: head.S: rename PMD_ORDER to PMD_ENTRY_ORDER

PMD_ORDER denotes order of magnitude for a PMD entry, i.e PMD entry
size is 2 ^ PMD_ORDER.

Rename PMD_ORDER to PMD_ENTRY_ORDER to allow a generic definition of
PMD_ORDER as order of a PMD allocation: (PMD_SHIFT - PAGE_SHIFT).

Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
 arch/arm/kernel/head.S | 34 +++++++++++++++++-----------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 500612d3da2e..29e2900178a1 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -38,10 +38,10 @@
 #ifdef CONFIG_ARM_LPAE
 	/* LPAE requires an additional page for the PGD */
 #define PG_DIR_SIZE	0x5000
-#define PMD_ORDER	3
+#define PMD_ENTRY_ORDER	3	/* PMD entry size is 2^PMD_ENTRY_ORDER */
 #else
 #define PG_DIR_SIZE	0x4000
-#define PMD_ORDER	2
+#define PMD_ENTRY_ORDER	2
 #endif
 
 	.globl	swapper_pg_dir
@@ -240,7 +240,7 @@ __create_page_tables:
 	mov	r6, r6, lsr #SECTION_SHIFT
 
 1:	orr	r3, r7, r5, lsl #SECTION_SHIFT	@ flags + kernel base
-	str	r3, [r4, r5, lsl #PMD_ORDER]	@ identity mapping
+	str	r3, [r4, r5, lsl #PMD_ENTRY_ORDER]	@ identity mapping
 	cmp	r5, r6
 	addlo	r5, r5, #1			@ next section
 	blo	1b
@@ -250,7 +250,7 @@ __create_page_tables:
 	 * set two variables to indicate the physical start and end of the
 	 * kernel.
 	 */
-	add	r0, r4, #KERNEL_OFFSET >> (SECTION_SHIFT - PMD_ORDER)
+	add	r0, r4, #KERNEL_OFFSET >> (SECTION_SHIFT - PMD_ENTRY_ORDER)
 	ldr	r6, =(_end - 1)
 	adr_l	r5, kernel_sec_start		@ _pa(kernel_sec_start)
 #if defined CONFIG_CPU_ENDIAN_BE8 || defined CONFIG_CPU_ENDIAN_BE32
@@ -259,8 +259,8 @@ __create_page_tables:
 	str	r8, [r5]			@ Save physical start of kernel (LE)
 #endif
 	orr	r3, r8, r7			@ Add the MMU flags
-	add	r6, r4, r6, lsr #(SECTION_SHIFT - PMD_ORDER)
-1:	str	r3, [r0], #1 << PMD_ORDER
+	add	r6, r4, r6, lsr #(SECTION_SHIFT - PMD_ENTRY_ORDER)
+1:	str	r3, [r0], #1 << PMD_ENTRY_ORDER
 	add	r3, r3, #1 << SECTION_SHIFT
 	cmp	r0, r6
 	bls	1b
@@ -280,14 +280,14 @@ __create_page_tables:
 	mov	r3, pc
 	mov	r3, r3, lsr #SECTION_SHIFT
 	orr	r3, r7, r3, lsl #SECTION_SHIFT
-	add	r0, r4,  #(XIP_START & 0xff000000) >> (SECTION_SHIFT - PMD_ORDER)
-	str	r3, [r0, #((XIP_START & 0x00f00000) >> SECTION_SHIFT) << PMD_ORDER]!
+	add	r0, r4,  #(XIP_START & 0xff000000) >> (SECTION_SHIFT - PMD_ENTRY_ORDER)
+	str	r3, [r0, #((XIP_START & 0x00f00000) >> SECTION_SHIFT) << PMD_ENTRY_ORDER]!
 	ldr	r6, =(_edata_loc - 1)
-	add	r0, r0, #1 << PMD_ORDER
-	add	r6, r4, r6, lsr #(SECTION_SHIFT - PMD_ORDER)
+	add	r0, r0, #1 << PMD_ENTRY_ORDER
+	add	r6, r4, r6, lsr #(SECTION_SHIFT - PMD_ENTRY_ORDER)
 1:	cmp	r0, r6
 	add	r3, r3, #1 << SECTION_SHIFT
-	strls	r3, [r0], #1 << PMD_ORDER
+	strls	r3, [r0], #1 << PMD_ENTRY_ORDER
 	bls	1b
 #endif
 
@@ -297,10 +297,10 @@ __create_page_tables:
 	 */
 	mov	r0, r2, lsr #SECTION_SHIFT
 	cmp	r2, #0
-	ldrne	r3, =FDT_FIXED_BASE >> (SECTION_SHIFT - PMD_ORDER)
+	ldrne	r3, =FDT_FIXED_BASE >> (SECTION_SHIFT - PMD_ENTRY_ORDER)
 	addne	r3, r3, r4
 	orrne	r6, r7, r0, lsl #SECTION_SHIFT
-	strne	r6, [r3], #1 << PMD_ORDER
+	strne	r6, [r3], #1 << PMD_ENTRY_ORDER
 	addne	r6, r6, #1 << SECTION_SHIFT
 	strne	r6, [r3]
 
@@ -319,7 +319,7 @@ __create_page_tables:
 	addruart r7, r3, r0
 
 	mov	r3, r3, lsr #SECTION_SHIFT
-	mov	r3, r3, lsl #PMD_ORDER
+	mov	r3, r3, lsl #PMD_ENTRY_ORDER
 
 	add	r0, r4, r3
 	mov	r3, r7, lsr #SECTION_SHIFT
@@ -349,7 +349,7 @@ __create_page_tables:
 	 * If we're using the NetWinder or CATS, we also need to map
 	 * in the 16550-type serial port for the debug messages
 	 */
-	add	r0, r4, #0xff000000 >> (SECTION_SHIFT - PMD_ORDER)
+	add	r0, r4, #0xff000000 >> (SECTION_SHIFT - PMD_ENTRY_ORDER)
 	orr	r3, r7, #0x7c000000
 	str	r3, [r0]
 #endif
@@ -359,10 +359,10 @@ __create_page_tables:
 	 * Similar reasons here - for debug.  This is
 	 * only for Acorn RiscPC architectures.
 	 */
-	add	r0, r4, #0x02000000 >> (SECTION_SHIFT - PMD_ORDER)
+	add	r0, r4, #0x02000000 >> (SECTION_SHIFT - PMD_ENTRY_ORDER)
 	orr	r3, r7, #0x02000000
 	str	r3, [r0]
-	add	r0, r4, #0xd8000000 >> (SECTION_SHIFT - PMD_ORDER)
+	add	r0, r4, #0xd8000000 >> (SECTION_SHIFT - PMD_ENTRY_ORDER)
 	str	r3, [r0]
 #endif
 #endif
-- 
2.34.1


-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 15/14] arm: Rename PMD_ORDER to PMD_BITS

[Matthew Wilcox]

On Mon, Jul 04, 2022 at 05:32:33AM +0100, Russell King (Oracle) wrote:
> On Sun, Jul 03, 2022 at 10:54:49PM +0100, Matthew Wilcox wrote:
> > On Sun, Jul 03, 2022 at 10:16:45PM +0100, Russell King (Oracle) wrote:
> > > On Sun, Jul 03, 2022 at 10:14:41PM +0100, Matthew Wilcox (Oracle) wrote:
> > > > This is the number of bits used by a PMD entry, not the order of a PMD.
> > > 
> > > No, it's not the number of bits. A PMD entry doesn't fit in 2 or 3 bits.
> > > This is even more confusing.
> > 
> > Well, what is it then?  The order of something is PAGE_SIZE << n, and
> > that doesn't seem to be what this is.
> 
> Where is it defined that "order" means "PAGE_SIZE << n" ?

include/asm-generic/getorder.h: * get_order - Determine the allocation order of a memory size

> "order" here is "order of magnitude" and in this case, it is 2^n, just
> like order of magnitude in base 10 is 10^n. So strictly, the usage
> here is completely correct, but if you describe "order" as "PAGE_SIZE <<
> n" that is no longer an order of magnitude, because it doesn't increase
> in an order of magnitude (iow, n = 2 isn't PAGE_SIZE * PAGE_SIZE).
> 
> Now, if you're trying to tell me that Linux has decided to define
> "order" to be something non-standard, I'll accept that, but then we
> shouldn't be renaming stuff that is using it in a standard way.
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 15/14] arm: Rename PMD_ORDER to PMD_BITS

[Russell King (Oracle)]

On Mon, Jul 04, 2022 at 11:48:39AM +0100, Matthew Wilcox wrote:
> On Mon, Jul 04, 2022 at 05:32:33AM +0100, Russell King (Oracle) wrote:
> > On Sun, Jul 03, 2022 at 10:54:49PM +0100, Matthew Wilcox wrote:
> > > On Sun, Jul 03, 2022 at 10:16:45PM +0100, Russell King (Oracle) wrote:
> > > > On Sun, Jul 03, 2022 at 10:14:41PM +0100, Matthew Wilcox (Oracle) wrote:
> > > > > This is the number of bits used by a PMD entry, not the order of a PMD.
> > > > 
> > > > No, it's not the number of bits. A PMD entry doesn't fit in 2 or 3 bits.
> > > > This is even more confusing.
> > > 
> > > Well, what is it then?  The order of something is PAGE_SIZE << n, and
> > > that doesn't seem to be what this is.
> > 
> > Where is it defined that "order" means "PAGE_SIZE << n" ?
> 
> include/asm-generic/getorder.h: * get_order - Determine the allocation order of a memory size

I really don't care - "order" is something that is a standard term,
and is entirely appropriate in its use in this case. The fact is,
this use conforms to the standard term usage, not some made up
Linux whim.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 15/14] arm: Rename PMD_ORDER to PMD_BITS

[Russell King (Oracle)]

On Mon, Jul 04, 2022 at 09:26:22AM +0300, Mike Rapoport wrote:
> I'd go with PMD_ENTRY_ORDER as Russell suggested last year.
> 
> From 6389dfb2e5ae5b040ca1c8f07a071d8da2873b13 Mon Sep 17 00:00:00 2001
> From: Mike Rapoport <rppt@linux.ibm.com>
> Date: Mon, 4 Jul 2022 09:17:40 +0300
> Subject: [PATCH] ARM: head.S: rename PMD_ORDER to PMD_ENTRY_ORDER
> 
> PMD_ORDER denotes order of magnitude for a PMD entry, i.e PMD entry
> size is 2 ^ PMD_ORDER.
> 
> Rename PMD_ORDER to PMD_ENTRY_ORDER to allow a generic definition of
> PMD_ORDER as order of a PMD allocation: (PMD_SHIFT - PAGE_SHIFT).
> 
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>

Yes, absolutely.

Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

I really don't buy the argument that we should not be using "order" here
and we need to make up some other random idiotic term just because Linux
uses "order" *elsewhere* for PAGE_SIZE * 2^n. The Linux kernel doesn't
get to redefine standard terms, and certainly doesn't get to demand that
one has to make up another name for a standard term because it conflicts
with some other usage of that term that's non-standard.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 15/14] arm: Rename PMD_ORDER to PMD_BITS

[Matthew Wilcox]

On Mon, Jul 04, 2022 at 12:32:20PM +0100, Russell King (Oracle) wrote:
> On Mon, Jul 04, 2022 at 11:48:39AM +0100, Matthew Wilcox wrote:
> > On Mon, Jul 04, 2022 at 05:32:33AM +0100, Russell King (Oracle) wrote:
> > > On Sun, Jul 03, 2022 at 10:54:49PM +0100, Matthew Wilcox wrote:
> > > > On Sun, Jul 03, 2022 at 10:16:45PM +0100, Russell King (Oracle) wrote:
> > > > > On Sun, Jul 03, 2022 at 10:14:41PM +0100, Matthew Wilcox (Oracle) wrote:
> > > > > > This is the number of bits used by a PMD entry, not the order of a PMD.
> > > > > 
> > > > > No, it's not the number of bits. A PMD entry doesn't fit in 2 or 3 bits.
> > > > > This is even more confusing.
> > > > 
> > > > Well, what is it then?  The order of something is PAGE_SIZE << n, and
> > > > that doesn't seem to be what this is.
> > > 
> > > Where is it defined that "order" means "PAGE_SIZE << n" ?
> > 
> > include/asm-generic/getorder.h: * get_order - Determine the allocation order of a memory size
> 
> I really don't care - "order" is something that is a standard term,

The word "order" has many different uses, just in mathematics alone (to
say nothing of its uses in biology, business, the military, religion,
or signal processing).

https://en.wikipedia.org/wiki/Order_(mathematics)

> and is entirely appropriate in its use in this case. The fact is,
> this use conforms to the standard term usage, not some made up
> Linux whim.

At the point where you're talking about PMD order, you're in the realm
of memory management, and using terms to mean something different from
their normal meaning within mm is only going to lead to confusion.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 15/14] arm: Rename PMD_ORDER to PMD_BITS

[Russell King (Oracle)]

On Mon, Jul 04, 2022 at 03:28:07PM +0100, Matthew Wilcox wrote:
> On Mon, Jul 04, 2022 at 12:32:20PM +0100, Russell King (Oracle) wrote:
> > On Mon, Jul 04, 2022 at 11:48:39AM +0100, Matthew Wilcox wrote:
> > > On Mon, Jul 04, 2022 at 05:32:33AM +0100, Russell King (Oracle) wrote:
> > > > On Sun, Jul 03, 2022 at 10:54:49PM +0100, Matthew Wilcox wrote:
> > > > > On Sun, Jul 03, 2022 at 10:16:45PM +0100, Russell King (Oracle) wrote:
> > > > > > On Sun, Jul 03, 2022 at 10:14:41PM +0100, Matthew Wilcox (Oracle) wrote:
> > > > > > > This is the number of bits used by a PMD entry, not the order of a PMD.
> > > > > > 
> > > > > > No, it's not the number of bits. A PMD entry doesn't fit in 2 or 3 bits.
> > > > > > This is even more confusing.
> > > > > 
> > > > > Well, what is it then?  The order of something is PAGE_SIZE << n, and
> > > > > that doesn't seem to be what this is.
> > > > 
> > > > Where is it defined that "order" means "PAGE_SIZE << n" ?
> > > 
> > > include/asm-generic/getorder.h: * get_order - Determine the allocation order of a memory size
> > 
> > I really don't care - "order" is something that is a standard term,
> 
> The word "order" has many different uses, just in mathematics alone (to
> say nothing of its uses in biology, business, the military, religion,
> or signal processing).
> 
> https://en.wikipedia.org/wiki/Order_(mathematics)

Right, and no one of those listed there has a claim to exclusive use of
the term over any of the others. That even lists the meaning that I'm
referring to - "Orders of Magnitude".

https://en.wikipedia.org/wiki/Order_of_magnitude

"Other orders of magnitude may be calculated using bases other than 10."

This usage you don't like is to use ORDER in the kernel to mean "orders
of magnitude in base 2" in it's purest form. The calculation here is
address = index << PMD_ORDER which is the same as address = index *
2^PMD_ORDER.

I have no suggestion for you other than what Mike has put forward, which
retains the use of ORDER. If you still object to the use of ORDER, then
I'm sorry, but I have no further suggestions.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel