x86: reuse the boot-time mappings of fixed_addresses

PATCH In review Xiao Guangrong 5 participants 10 messages Aug 23, 2009 – Sep 4, 2009

Subsystems (4)

Memory management x86 MM core x86 MM

lore

Share & tools

lore

Xiao Guangrong

author

2009-08-23 02:31 UTC #0 lore raw

PATCH 1/1 x86: reuse the boot-time mappings of fixed_addresses

From: Xiao Guangrong <[email protected]>

Some fixed_addresses items are only used when system boot, after boot, they are free but no way to use, like early ioremap area. They are wasted for us, we can reuse them after system boot.

In this patch, we put them in permanent kmap's area and expand vmalloc's address range. In boot time, reserve them in permanent_kmaps_init() to avoid multiple used, after system boot, we unreserved them then user can use it.

Signed-off-by Xiao Guangrong <[email protected]>

---
 arch/x86/include/asm/fixmap.h           |    2 ++
 arch/x86/include/asm/pgtable_32_types.h |    4 ++--
 arch/x86/mm/init_32.c                   |    8 ++++++++
 include/linux/highmem.h                 |    2 ++
 mm/highmem.c                            |   26 ++++++++++++++++++++++++++
 5 files changed, 40 insertions(+), 2 deletions(-)

arch/x86/include/asm/fixmap.h +2 -0

index 7b2d71d..604f135 100644
@@ -142,6 +142,8 @@ extern void reserve_top_address(unsigned long reserve);
 #define FIXADDR_BOOT_SIZE	(__end_of_fixed_addresses << PAGE_SHIFT)
 #define FIXADDR_START		(FIXADDR_TOP - FIXADDR_SIZE)
 #define FIXADDR_BOOT_START	(FIXADDR_TOP - FIXADDR_BOOT_SIZE)
+#define FIXMAP_REUSE		(__end_of_fixed_addresses - 	\
+				 __end_of_permanent_fixed_addresses)
 
 extern int fixmaps_set;

arch/x86/include/asm/pgtable_32_types.h +2 -2

index 5e67c15..328b8af 100644
@@ -37,8 +37,8 @@ extern bool __vmalloc_start_set; /* set once high_memory is set */
 #define LAST_PKMAP 1024
 #endif
 
-#define PKMAP_BASE ((FIXADDR_BOOT_START - PAGE_SIZE * (LAST_PKMAP + 1))	\
-		    & PMD_MASK)
+#define PKMAP_BASE ((FIXADDR_BOOT_START - PAGE_SIZE * (LAST_PKMAP -	\
+		    FIXMAP_REUSE + 1)) & PMD_MASK)
 
 #ifdef CONFIG_HIGHMEM
 # define VMALLOC_END	(PKMAP_BASE - 2 * PAGE_SIZE)

arch/x86/mm/init_32.c +8 -0

index 3cd7711..595e485 100644
@@ -410,8 +410,16 @@ static void __init permanent_kmaps_init(pgd_t *pgd_base)
 	pmd = pmd_offset(pud, vaddr);
 	pte = pte_offset_kernel(pmd, vaddr);
 	pkmap_page_table = pte;
+	kmaps_reserve(LAST_PKMAP-FIXMAP_REUSE, LAST_PKMAP-1);
 }
 
+static int __init permanent_kmaps_unreserve(void)
+{
+	kmaps_unreserve(LAST_PKMAP-FIXMAP_REUSE, LAST_PKMAP-1);
+	return 0;
+}
+late_initcall(permanent_kmaps_unreserve);
+
 static void __init add_one_highpage_init(struct page *page, int pfn)
 {
 	ClearPageReserved(page);

include/linux/highmem.h +2 -0

index 211ff44..984c4c9 100644
@@ -41,6 +41,8 @@ unsigned int nr_free_highpages(void);
 extern unsigned long totalhigh_pages;
 
 void kmap_flush_unused(void);
+void kmaps_reserve(int start, int end);
+void kmaps_unreserve(int start, int end);
 
 #else /* CONFIG_HIGHMEM */

mm/highmem.c +26 -0

index 25878cc..a481fa7 100644
@@ -85,6 +85,32 @@ static DECLARE_WAIT_QUEUE_HEAD(pkmap_map_wait);
 		do { spin_unlock(&kmap_lock); (void)(flags); } while (0)
 #endif
 
+void kmaps_reserve(int start, int end)
+{
+	int i;
+
+	lock_kmap();
+	for (i = start; i <= end; i++) {
+		BUG_ON(pkmap_count[i]);
+		pkmap_count[i] = -1;
+	}
+	unlock_kmap();
+}
+
+void kmaps_unreserve(int start, int end)
+{
+	int i;
+
+	lock_kmap();
+	for (i = start; i <= end; i++) {
+		BUG_ON(pkmap_count[i] != -1);
+		pkmap_count[i] = 0;
+	}
+
+	flush_tlb_kernel_range(PKMAP_ADDR(start), PKMAP_ADDR(end));
+	unlock_kmap();
+}
+
 static void flush_all_zero_pkmaps(void)
 {
 	int i;

Signature · 1 line

1.6.0.4

Ingo Molnar

2009-08-29 11:01 UTC #1 lore raw

Quoted 11 lines · Xiao Guangrong

From: Xiao Guangrong <[email protected]>
Some fixed_addresses items are only used when system boot, after boot, they are free but no way to use, like early ioremap area. They are wasted for us, we can reuse them after system boot.
In this patch, we put them in permanent kmap's area and expand vmalloc's address range. In boot time, reserve them in permanent_kmaps_init() to avoid multiple used, after system boot, we unreserved them then user can use it.

Quoted 8 lines

Signed-off-by Xiao Guangrong <[email protected]>

---
 arch/x86/include/asm/fixmap.h           |    2 ++
 arch/x86/include/asm/pgtable_32_types.h |    4 ++--
 arch/x86/mm/init_32.c                   |    8 ++++++++
 include/linux/highmem.h                 |    2 ++
 mm/highmem.c                            |   26 ++++++++++++++++++++++++++
 5 files changed, 40 insertions(+), 2 deletions(-)

I'm wondering, how much space do we save this way, on a typical bootup on a typical PC?

Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

H. Peter Anvin

reviewer

2009-08-29 18:17 UTC #2 lore raw

Quoted 17 lines · Ingo Molnar

Quoted 6 lines · Xiao Guangrong
From: Xiao Guangrong <[email protected]>
Some fixed_addresses items are only used when system boot, after boot, they are free but no way to use, like early ioremap area. They are wasted for us, we can reuse them after system boot.
In this patch, we put them in permanent kmap's area and expand vmalloc's address range. In boot time, reserve them in permanent_kmaps_init() to avoid multiple used, after system boot, we unreserved them then user can use it.
Quoted 8 lines
Signed-off-by Xiao Guangrong <[email protected]>
---
 arch/x86/include/asm/fixmap.h           |    2 ++
 arch/x86/include/asm/pgtable_32_types.h |    4 ++--
 arch/x86/mm/init_32.c                   |    8 ++++++++
 include/linux/highmem.h                 |    2 ++
 mm/highmem.c                            |   26 ++++++++++++++++++++++++++
 5 files changed, 40 insertions(+), 2 deletions(-)

Quoted 2 lines

I'm wondering, how much space do we save this way, on a typical bootup on a typical PC?

Not a huge lot... a few dozen pages.

-hpa

Ingo Molnar

2009-08-31 08:26 UTC #3 lore raw

Quoted 23 lines · H. Peter Anvin

Quoted 22 lines · Ingo Molnar
Quoted 19 lines · Xiao Guangrong
From: Xiao Guangrong <[email protected]>
Some fixed_addresses items are only used when system boot, after boot, they are free but no way to use, like early ioremap area. They are wasted for us, we can reuse them after system boot.
In this patch, we put them in permanent kmap's area and expand vmalloc's address range. In boot time, reserve them in permanent_kmaps_init() to avoid multiple used, after system boot, we unreserved them then user can use it.
Signed-off-by Xiao Guangrong <[email protected]>
---
 arch/x86/include/asm/fixmap.h           |    2 ++
 arch/x86/include/asm/pgtable_32_types.h |    4 ++--
 arch/x86/mm/init_32.c                   |    8 ++++++++
 include/linux/highmem.h                 |    2 ++
 mm/highmem.c                            |   26 ++++++++++++++++++++++++++
 5 files changed, 40 insertions(+), 2 deletions(-)

Quoted 5 lines

Quoted 3 lines
I'm wondering, how much space do we save this way, on a typical bootup on a typical PC?
Not a huge lot... a few dozen pages.

I guess it's still worth doing - what do you think?

Ingo

Jeremy Fitzhardinge

2009-09-01 00:29 UTC #4 lore raw

Quoted 8 lines · Ingo Molnar

Quoted 6 lines
Quoted 4 lines
I'm wondering, how much space do we save this way, on a typical bootup on a typical PC?
Not a huge lot... a few dozen pages.
I guess it's still worth doing - what do you think?

It hardly seems worth it, but I guess it isn't much code. Will having an apparent overlap of vmalloc and fixmap spaces confuse anything?

Ingo Molnar

2009-09-04 07:34 UTC #5 lore raw

Quoted 11 lines · Jeremy Fitzhardinge

Quoted 8 lines · Ingo Molnar
Quoted 6 lines
Quoted 4 lines
I'm wondering, how much space do we save this way, on a typical bootup on a typical PC?
Not a huge lot... a few dozen pages.
I guess it's still worth doing - what do you think?
It hardly seems worth it, but I guess it isn't much code. [...]

Ok, i understood this as an Acked-by from you - lemme know if that's wrong ;-)

Quoted 2 lines

[...] Will having an apparent overlap of vmalloc and fixmap spaces confuse anything?

At most perhaps some debug tools - kcrash & co.

Ingo

tip-bot for Xiao Guangrong

2009-09-04 08:00 UTC #9 lore raw

[tip:x86/mm] x86: Reuse the boot-time mappings of fixed_addresses

In reply to Xiao Guangrong

Commit-ID:  d9fd2e4645eeb87415618fd0a8f5c992e6b43b37
Gitweb:     http://git.kernel.org/tip/d9fd2e4645eeb87415618fd0a8f5c992e6b43b37
Author:     Xiao Guangrong <[email protected]>
AuthorDate: Sun, 23 Aug 2009 10:35:10 +0800
Committer:  Ingo Molnar <[email protected]>
CommitDate: Fri, 4 Sep 2009 09:35:17 +0200

x86: Reuse the boot-time mappings of fixed_addresses

Some fixed_addresses items are only used when system boot, after boot, they are free but no way to use, like early ioremap area. They are wasted for us, we can reuse them after system boot.

Signed-off-by Xiao Guangrong <[email protected]>

Acked-by Jeremy Fitzhardinge <[email protected]>

Cc Rusty Russell <[email protected]>

Cc Jens Axboe <[email protected]>

Cc [email protected]

Cc Andrew Morton <[email protected]>

LKML-Reference: <[email protected]>

Signed-off-by Ingo Molnar <[email protected]>

---
 arch/x86/include/asm/fixmap.h           |    2 ++
 arch/x86/include/asm/pgtable_32_types.h |    4 ++--
 arch/x86/mm/init_32.c                   |    8 ++++++++
 include/linux/highmem.h                 |    2 ++
 mm/highmem.c                            |   26 ++++++++++++++++++++++++++
 5 files changed, 40 insertions(+), 2 deletions(-)

arch/x86/include/asm/fixmap.h +2 -0

index 7b2d71d..604f135 100644
@@ -142,6 +142,8 @@ extern void reserve_top_address(unsigned long reserve);
 #define FIXADDR_BOOT_SIZE	(__end_of_fixed_addresses << PAGE_SHIFT)
 #define FIXADDR_START		(FIXADDR_TOP - FIXADDR_SIZE)
 #define FIXADDR_BOOT_START	(FIXADDR_TOP - FIXADDR_BOOT_SIZE)
+#define FIXMAP_REUSE		(__end_of_fixed_addresses - 	\
+				 __end_of_permanent_fixed_addresses)
 
 extern int fixmaps_set;

arch/x86/include/asm/pgtable_32_types.h +2 -2

index 5e67c15..328b8af 100644
@@ -37,8 +37,8 @@ extern bool __vmalloc_start_set; /* set once high_memory is set */
 #define LAST_PKMAP 1024
 #endif
 
-#define PKMAP_BASE ((FIXADDR_BOOT_START - PAGE_SIZE * (LAST_PKMAP + 1))	\
-		    & PMD_MASK)
+#define PKMAP_BASE ((FIXADDR_BOOT_START - PAGE_SIZE * (LAST_PKMAP -	\
+		    FIXMAP_REUSE + 1)) & PMD_MASK)
 
 #ifdef CONFIG_HIGHMEM
 # define VMALLOC_END	(PKMAP_BASE - 2 * PAGE_SIZE)

arch/x86/mm/init_32.c +8 -0

index 3cd7711..595e485 100644
@@ -410,8 +410,16 @@ static void __init permanent_kmaps_init(pgd_t *pgd_base)
 	pmd = pmd_offset(pud, vaddr);
 	pte = pte_offset_kernel(pmd, vaddr);
 	pkmap_page_table = pte;
+	kmaps_reserve(LAST_PKMAP-FIXMAP_REUSE, LAST_PKMAP-1);
 }
 
+static int __init permanent_kmaps_unreserve(void)
+{
+	kmaps_unreserve(LAST_PKMAP-FIXMAP_REUSE, LAST_PKMAP-1);
+	return 0;
+}
+late_initcall(permanent_kmaps_unreserve);
+
 static void __init add_one_highpage_init(struct page *page, int pfn)
 {
 	ClearPageReserved(page);

include/linux/highmem.h +2 -0

index 211ff44..984c4c9 100644
@@ -41,6 +41,8 @@ unsigned int nr_free_highpages(void);
 extern unsigned long totalhigh_pages;
 
 void kmap_flush_unused(void);
+void kmaps_reserve(int start, int end);
+void kmaps_unreserve(int start, int end);
 
 #else /* CONFIG_HIGHMEM */

mm/highmem.c +26 -0

index 25878cc..a481fa7 100644
@@ -85,6 +85,32 @@ static DECLARE_WAIT_QUEUE_HEAD(pkmap_map_wait);
 		do { spin_unlock(&kmap_lock); (void)(flags); } while (0)
 #endif
 
+void kmaps_reserve(int start, int end)
+{
+	int i;
+
+	lock_kmap();
+	for (i = start; i <= end; i++) {
+		BUG_ON(pkmap_count[i]);
+		pkmap_count[i] = -1;
+	}
+	unlock_kmap();
+}
+
+void kmaps_unreserve(int start, int end)
+{
+	int i;
+
+	lock_kmap();
+	for (i = start; i <= end; i++) {
+		BUG_ON(pkmap_count[i] != -1);
+		pkmap_count[i] = 0;
+	}
+
+	flush_tlb_kernel_range(PKMAP_ADDR(start), PKMAP_ADDR(end));
+	unlock_kmap();
+}
+
 static void flush_all_zero_pkmaps(void)
 {
 	int i;

Jeremy Fitzhardinge

2009-09-04 15:47 UTC #6 lore raw

In reply to Ingo Molnar

Quoted 5 lines · Ingo Molnar

Quoted 2 lines
It hardly seems worth it, but I guess it isn't much code. [...]
Ok, i understood this as an Acked-by from you - lemme know if that's wrong ;-)

That's a bit proactive. It's more "Meh-I-suppose-d-by: ".

H. Peter Anvin

reviewer

2009-09-04 16:17 UTC #7 lore raw

Quoted 9 lines · Jeremy Fitzhardinge

Quoted 5 lines · Ingo Molnar
Quoted 2 lines
It hardly seems worth it, but I guess it isn't much code. [...]
Ok, i understood this as an Acked-by from you - lemme know if that's wrong ;-)
That's a bit proactive. It's more "Meh-I-suppose-d-by: ".

Pretty much. I suspect we'll have to undo this when we fix the fixmap, since it will no longer be adjacent to the vmalloc range.

-hpa

Signature · 8 lines

H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Ingo Molnar

2009-09-04 18:55 UTC #8 lore raw

Quoted 8 lines · H. Peter Anvin

Quoted 7 lines · Jeremy Fitzhardinge
Quoted 5 lines · Ingo Molnar
Quoted 2 lines
It hardly seems worth it, but I guess it isn't much code. [...]
Ok, i understood this as an Acked-by from you - lemme know if that's wrong ;-)

Quoted 5 lines

Quoted 2 lines
That's a bit proactive. It's more "Meh-I-suppose-d-by: ".
Pretty much. I suspect we'll have to undo this when we fix the fixmap, since it will no longer be adjacent to the vmalloc range.

Ok, i've removed the patch from tip:x86/mm ...

Ingo