x86: reuse the boot-time mappings of fixed_addresses
Subsystems (4)
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.
--- 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
Quoted 11 lines · Xiao Guangrong
From: Xiao Guangrong <[email protected]>
Some
fixed_addressesitems 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
reviewerQuoted 17 lines · Ingo Molnar
Quoted 6 lines · Xiao Guangrong
From: Xiao Guangrong <[email protected]>
Some
fixed_addressesitems 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
--
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>
Quoted 23 lines · H. Peter Anvin
Quoted 22 lines · Ingo Molnar
Quoted 19 lines · Xiao Guangrong
From: Xiao Guangrong <[email protected]>
Some
fixed_addressesitems 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
--
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>
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?
J
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
--
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>
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: ".
J
--
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
reviewerQuoted 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>
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
--
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>
[tip:x86/mm] x86: Reuse the boot-time mappings of fixed_addresses
In reply to Xiao GuangrongCommit-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.
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.
LKML-Reference: <[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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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;