* [PATCH 0/2] x86: Speed up ioremap operations
@ 2014-08-29 19:16 Mike Travis
2014-08-29 19:16 ` [PATCH 1/2] x86: Optimize resource lookups for ioremap Mike Travis
2014-08-29 19:16 ` [PATCH 2/2] x86: Use optimized ioresource lookup in ioremap function Mike Travis
0 siblings, 2 replies; 5+ messages in thread
From: Mike Travis @ 2014-08-29 19:16 UTC (permalink / raw)
To: mingo, tglx, hpa
Cc: akpm, msalter, dyoung, riel, peterz, mgorman, linux-kernel, x86,
linux-mm
We have a large university system in the UK that is experiencing
very long delays modprobing the driver for a specific I/O device.
The delay is from 8-10 minutes per device and there are 31 devices
in the system. This 4 to 5 hour delay in starting up those I/O
devices is very much a burden on the customer.
There are two causes for requiring a restart/reload of the drivers.
First is periodic preventive maintenance (PM) and the second is if
any of the devices experience a fatal error. Both of these trigger
this excessively long delay in bringing the system back up to full
capability.
The problem was tracked down to a very slow IOREMAP operation and
the excessively long ioresource lookup to insure that the user is
not attempting to ioremap RAM. These patches provide a speed up
to that function.
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH 1/2] x86: Optimize resource lookups for ioremap
2014-08-29 19:16 [PATCH 0/2] x86: Speed up ioremap operations Mike Travis
@ 2014-08-29 19:16 ` Mike Travis
2014-08-29 19:16 ` [PATCH 2/2] x86: Use optimized ioresource lookup in ioremap function Mike Travis
1 sibling, 0 replies; 5+ messages in thread
From: Mike Travis @ 2014-08-29 19:16 UTC (permalink / raw)
To: mingo, tglx, hpa
Cc: akpm, msalter, dyoung, riel, peterz, mgorman, linux-kernel, x86,
linux-mm, Alex Thorlton
[-- Attachment #1: add-get-resource-type --]
[-- Type: text/plain, Size: 2894 bytes --]
Since the ioremap operation is verifying that the specified address range
is NOT RAM, it will search the entire ioresource list if the condition
is true. To make matters worse, it does this one 4k page at a time.
For a 128M BAR region this is 32 passes to determine the entire region
does not contain any RAM addresses.
This patch provides another resource lookup function, region_is_ram,
that searches for the entire region specified, verifying that it is
completely contained within the resource region. If it is found, then
it is checked to be RAM or not, within a single pass.
The return result reflects if it was found or not (-1), and whether it is
RAM (1) or not (0). This allows the caller to fallback to the previous
page by page search if it was not found.
Signed-off-by: Mike Travis <travis@sgi.com>
Acked-by: Alex Thorlton <athorlton@sgi.com>
Reviewed-by: Cliff Wickman <cpw@sgi.com>
---
v2: remove 'weak' and EXPORT_SYMBOL_GPL from region_is_ram()
---
include/linux/mm.h | 1 +
kernel/resource.c | 36 ++++++++++++++++++++++++++++++++++++
2 files changed, 37 insertions(+)
--- linux.orig/include/linux/mm.h
+++ linux/include/linux/mm.h
@@ -346,6 +346,7 @@ static inline int put_page_unless_one(st
}
extern int page_is_ram(unsigned long pfn);
+extern int region_is_ram(resource_size_t phys_addr, unsigned long size);
/* Support for virtually mapped pages */
struct page *vmalloc_to_page(const void *addr);
--- linux.orig/kernel/resource.c
+++ linux/kernel/resource.c
@@ -494,6 +494,42 @@ int __weak page_is_ram(unsigned long pfn
}
EXPORT_SYMBOL_GPL(page_is_ram);
+/*
+ * Search for a resouce entry that fully contains the specified region.
+ * If found, return 1 if it is RAM, 0 if not.
+ * If not found, or region is not fully contained, return -1
+ *
+ * Used by the ioremap functions to insure user not remapping RAM and is as
+ * vast speed up over walking through the resource table page by page.
+ */
+int region_is_ram(resource_size_t start, unsigned long size)
+{
+ struct resource *p;
+ resource_size_t end = start + size - 1;
+ int flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+ const char *name = "System RAM";
+ int ret = -1;
+
+ read_lock(&resource_lock);
+ for (p = iomem_resource.child; p ; p = p->sibling) {
+ if (end < p->start)
+ continue;
+
+ if (p->start <= start && end <= p->end) {
+ /* resource fully contains region */
+ if ((p->flags != flags) || strcmp(p->name, name))
+ ret = 0;
+ else
+ ret = 1;
+ break;
+ }
+ if (p->end < start)
+ break; /* not found */
+ }
+ read_unlock(&resource_lock);
+ return ret;
+}
+
void __weak arch_remove_reservations(struct resource *avail)
{
}
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 5+ messages in thread* [PATCH 2/2] x86: Use optimized ioresource lookup in ioremap function
2014-08-29 19:16 [PATCH 0/2] x86: Speed up ioremap operations Mike Travis
2014-08-29 19:16 ` [PATCH 1/2] x86: Optimize resource lookups for ioremap Mike Travis
@ 2014-08-29 19:16 ` Mike Travis
1 sibling, 0 replies; 5+ messages in thread
From: Mike Travis @ 2014-08-29 19:16 UTC (permalink / raw)
To: mingo, tglx, hpa
Cc: akpm, msalter, dyoung, riel, peterz, mgorman, linux-kernel, x86,
linux-mm, Alex Thorlton
[-- Attachment #1: use-get-resource-type --]
[-- Type: text/plain, Size: 2028 bytes --]
This patch uses the optimized ioresource lookup, "region_is_ram", for
the ioremap function. If the region is not found, it falls back to the
"page_is_ram" function. If it is found and it is RAM, then the usual
warning message is issued, and the ioremap operation is aborted.
Otherwise, the ioremap operation continues.
Signed-off-by: Mike Travis <travis@sgi.com>
Acked-by: Alex Thorlton <athorlton@sgi.com>
Reviewed-by: Cliff Wickman <cpw@sgi.com>
---
v2: slight rearrangement of code
---
arch/x86/mm/ioremap.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
--- linux.orig/arch/x86/mm/ioremap.c
+++ linux/arch/x86/mm/ioremap.c
@@ -86,6 +86,7 @@ static void __iomem *__ioremap_caller(re
pgprot_t prot;
int retval;
void __iomem *ret_addr;
+ int ram_region;
/* Don't allow wraparound or zero size */
last_addr = phys_addr + size - 1;
@@ -108,12 +109,23 @@ static void __iomem *__ioremap_caller(re
/*
* Don't allow anybody to remap normal RAM that we're using..
*/
- pfn = phys_addr >> PAGE_SHIFT;
- last_pfn = last_addr >> PAGE_SHIFT;
- if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
- __ioremap_check_ram) == 1)
+ /* First check if whole region can be identified as RAM or not */
+ ram_region = region_is_ram(phys_addr, size);
+ if (ram_region > 0) {
+ WARN_ONCE(1, "ioremap on RAM at 0x%lx - 0x%lx\n",
+ (unsigned long int)phys_addr,
+ (unsigned long int)last_addr);
return NULL;
+ }
+ /* If could not be identified(-1), check page by page */
+ if (ram_region < 0) {
+ pfn = phys_addr >> PAGE_SHIFT;
+ last_pfn = last_addr >> PAGE_SHIFT;
+ if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
+ __ioremap_check_ram) == 1)
+ return NULL;
+ }
/*
* Mappings have to be page-aligned
*/
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH 0/2] x86: Speed up ioremap operations
@ 2014-08-29 19:53 Mike Travis
2014-08-29 19:53 ` [PATCH 2/2] x86: Use optimized ioresource lookup in ioremap function Mike Travis
0 siblings, 1 reply; 5+ messages in thread
From: Mike Travis @ 2014-08-29 19:53 UTC (permalink / raw)
To: mingo, tglx, hpa
Cc: akpm, msalter, dyoung, riel, peterz, mgorman, linux-kernel, x86,
linux-mm
We have a large university system in the UK that is experiencing
very long delays modprobing the driver for a specific I/O device.
The delay is from 8-10 minutes per device and there are 31 devices
in the system. This 4 to 5 hour delay in starting up those I/O
devices is very much a burden on the customer.
There are two causes for requiring a restart/reload of the drivers.
First is periodic preventive maintenance (PM) and the second is if
any of the devices experience a fatal error. Both of these trigger
this excessively long delay in bringing the system back up to full
capability.
The problem was tracked down to a very slow IOREMAP operation and
the excessively long ioresource lookup to insure that the user is
not attempting to ioremap RAM. These patches provide a speed up
to that function.
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH 2/2] x86: Use optimized ioresource lookup in ioremap function
2014-08-29 19:53 [PATCH 0/2] x86: Speed up ioremap operations Mike Travis
@ 2014-08-29 19:53 ` Mike Travis
0 siblings, 0 replies; 5+ messages in thread
From: Mike Travis @ 2014-08-29 19:53 UTC (permalink / raw)
To: mingo, tglx, hpa
Cc: akpm, msalter, dyoung, riel, peterz, mgorman, linux-kernel, x86,
linux-mm, Alex Thorlton, stable
[-- Attachment #1: use-get-resource-type --]
[-- Type: text/plain, Size: 2078 bytes --]
This patch uses the optimized ioresource lookup, "region_is_ram", for
the ioremap function. If the region is not found, it falls back to the
"page_is_ram" function. If it is found and it is RAM, then the usual
warning message is issued, and the ioremap operation is aborted.
Otherwise, the ioremap operation continues.
Signed-off-by: Mike Travis <travis@sgi.com>
Acked-by: Alex Thorlton <athorlton@sgi.com>
Reviewed-by: Cliff Wickman <cpw@sgi.com>
Cc: <stable@vger.kernel.org>
---
v2: slight rearrangement of code
v3: added Cc: stable
---
arch/x86/mm/ioremap.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
--- linux.orig/arch/x86/mm/ioremap.c
+++ linux/arch/x86/mm/ioremap.c
@@ -86,6 +86,7 @@ static void __iomem *__ioremap_caller(re
pgprot_t prot;
int retval;
void __iomem *ret_addr;
+ int ram_region;
/* Don't allow wraparound or zero size */
last_addr = phys_addr + size - 1;
@@ -108,12 +109,23 @@ static void __iomem *__ioremap_caller(re
/*
* Don't allow anybody to remap normal RAM that we're using..
*/
- pfn = phys_addr >> PAGE_SHIFT;
- last_pfn = last_addr >> PAGE_SHIFT;
- if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
- __ioremap_check_ram) == 1)
+ /* First check if whole region can be identified as RAM or not */
+ ram_region = region_is_ram(phys_addr, size);
+ if (ram_region > 0) {
+ WARN_ONCE(1, "ioremap on RAM at 0x%lx - 0x%lx\n",
+ (unsigned long int)phys_addr,
+ (unsigned long int)last_addr);
return NULL;
+ }
+ /* If could not be identified(-1), check page by page */
+ if (ram_region < 0) {
+ pfn = phys_addr >> PAGE_SHIFT;
+ last_pfn = last_addr >> PAGE_SHIFT;
+ if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
+ __ioremap_check_ram) == 1)
+ return NULL;
+ }
/*
* Mappings have to be page-aligned
*/
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH 0/2] x86: Speed up ioremap operations
@ 2014-08-27 22:59 Mike Travis
2014-08-27 22:59 ` [PATCH 2/2] x86: Use optimized ioresource lookup in ioremap function Mike Travis
0 siblings, 1 reply; 5+ messages in thread
From: Mike Travis @ 2014-08-27 22:59 UTC (permalink / raw)
To: mingo, tglx, hpa
Cc: akpm, msalter, dyoung, riel, peterz, mgorman, linux-kernel, x86,
linux-mm
We have a large university system in the UK that is experiencing
very long delays modprobing the driver for a specific I/O device.
The delay is from 8-10 minutes per device and there are 31 devices
in the system. This 4 to 5 hour delay in starting up those I/O
devices is very much a burden on the customer.
There are two causes for requiring a restart/reload of the drivers.
First is periodic preventive maintenance (PM) and the second is if
any of the devices experience a fatal error. Both of these trigger
this excessively long delay in bringing the system back up to full
capability.
The problem was tracked down to a very slow IOREMAP operation and
the excessively long ioresource lookup to insure that the user is
not attempting to ioremap RAM. These patches provide a speed up
to that function.
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH 2/2] x86: Use optimized ioresource lookup in ioremap function
2014-08-27 22:59 [PATCH 0/2] x86: Speed up ioremap operations Mike Travis
@ 2014-08-27 22:59 ` Mike Travis
0 siblings, 0 replies; 5+ messages in thread
From: Mike Travis @ 2014-08-27 22:59 UTC (permalink / raw)
To: mingo, tglx, hpa
Cc: akpm, msalter, dyoung, riel, peterz, mgorman, linux-kernel, x86,
linux-mm, Alex Thorlton
[-- Attachment #1: use-get-resource-type --]
[-- Type: text/plain, Size: 2024 bytes --]
This patch uses the optimized ioresource lookup, "region_is_ram", for
the ioremap function. If the region is not found, it falls back to the
"page_is_ram" function. If it is found and it is RAM, then the usual
warning message is issued, and the ioremap operation is aborted.
Otherwise, the ioremap operation continues.
Signed-off-by: Mike Travis <travis@sgi.com>
Acked-by: Alex Thorlton <athorlton@sgi.com>
Reviewed-by: Cliff Wickman <cpw@sgi.com>
---
arch/x86/mm/ioremap.c | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
--- linux.orig/arch/x86/mm/ioremap.c
+++ linux/arch/x86/mm/ioremap.c
@@ -86,6 +86,7 @@ static void __iomem *__ioremap_caller(re
pgprot_t prot;
int retval;
void __iomem *ret_addr;
+ int ram_region;
/* Don't allow wraparound or zero size */
last_addr = phys_addr + size - 1;
@@ -108,12 +109,23 @@ static void __iomem *__ioremap_caller(re
/*
* Don't allow anybody to remap normal RAM that we're using..
*/
- pfn = phys_addr >> PAGE_SHIFT;
- last_pfn = last_addr >> PAGE_SHIFT;
- if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
- __ioremap_check_ram) == 1)
- return NULL;
+ /* First check if whole region can be identified as RAM or not */
+ ram_region = region_is_ram(phys_addr, size);
+ /* If is RAM(1) or could not be identified(-1), check page by page */
+ if (ram_region) {
+ pfn = phys_addr >> PAGE_SHIFT;
+ last_pfn = last_addr >> PAGE_SHIFT;
+ if (ram_region > 0) {
+ WARN_ONCE(1, "ioremap on RAM at 0x%lx - 0x%lx\n",
+ (long unsigned int)phys_addr,
+ (long unsigned int)last_addr);
+ return NULL;
+ }
+ if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
+ __ioremap_check_ram) == 1)
+ return NULL;
+ }
/*
* Mappings have to be page-aligned
*/
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-08-29 19:53 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-29 19:16 [PATCH 0/2] x86: Speed up ioremap operations Mike Travis
2014-08-29 19:16 ` [PATCH 1/2] x86: Optimize resource lookups for ioremap Mike Travis
2014-08-29 19:16 ` [PATCH 2/2] x86: Use optimized ioresource lookup in ioremap function Mike Travis
-- strict thread matches above, loose matches on Subject: below --
2014-08-29 19:53 [PATCH 0/2] x86: Speed up ioremap operations Mike Travis
2014-08-29 19:53 ` [PATCH 2/2] x86: Use optimized ioresource lookup in ioremap function Mike Travis
2014-08-27 22:59 [PATCH 0/2] x86: Speed up ioremap operations Mike Travis
2014-08-27 22:59 ` [PATCH 2/2] x86: Use optimized ioresource lookup in ioremap function Mike Travis
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox