Re: [PATCH 1/2] x86: Optimize resource lookups for ioremap
On Wed, 27 Aug 2014 16:54:18 -0700 Mike Travis wrote: > > If we're still at 1+ hours then little bodges like this are nowhere > > near sufficient and sterner stuff will be needed. > > > > Do we actually need the test? My googling turns up zero instances of > > anyone reporting the "ioremap on RAM pfn" warning. > > We get them more than we like, mostly from 3rd party vendors, and > esp. those that merely port their windows drivers to linux. Dang. So wrapping the check in CONFIG_DEBUG_VM would be problematic? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86: Optimize resource lookups for ioremap
On 8/27/2014 4:37 PM, Andrew Morton wrote: > On Wed, 27 Aug 2014 16:25:24 -0700 Mike Travis wrote: > >>> >>> >>> >>> Doing strcmp("System RAM") is rather a hack. Is there nothing in >>> resource.flags which can be used? Or added otherwise? >> >> I agree except this mimics the page_is_ram function: >> >> while ((res.start < res.end) && >> (find_next_iomem_res(, "System RAM", true) >= 0)) { > > Yeah. Sigh. > >> So it passes the same literal string which then find_next does the >> same strcmp on it: >> >> if (p->flags != res->flags) >> continue; >> if (name && strcmp(p->name, name)) >> continue; >> >> I should add back in the check to insure name is not NULL. > > If we're still at 1+ hours then little bodges like this are nowhere > near sufficient and sterner stuff will be needed. > > Do we actually need the test? My googling turns up zero instances of > anyone reporting the "ioremap on RAM pfn" warning. We get them more than we like, mostly from 3rd party vendors, and esp. those that merely port their windows drivers to linux. > > Where's the rest of the time being spent? This device has a huge internal memory and many processing devices. So it loads up an operating system and starts a bunch of pseudo network connections through the PCI-e/driver interface. It was hard to determine what percentage the ioremap played in the overall starting time (based on what info we were able to collect). But the ioremap was definitely the largest part of the 'modprobe' operation. I think realistically that's all we have control over. (But as I mentioned, we are encouraging the vendor to look into starting the devices in parallel. The overlap will cut down the overall time by quite a bit, being there are 31 devices.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86: Optimize resource lookups for ioremap
On Wed, 27 Aug 2014 16:25:24 -0700 Mike Travis wrote: > > > > > > > > Doing strcmp("System RAM") is rather a hack. Is there nothing in > > resource.flags which can be used? Or added otherwise? > > I agree except this mimics the page_is_ram function: > > while ((res.start < res.end) && > (find_next_iomem_res(, "System RAM", true) >= 0)) { Yeah. Sigh. > So it passes the same literal string which then find_next does the > same strcmp on it: > > if (p->flags != res->flags) > continue; > if (name && strcmp(p->name, name)) > continue; > > I should add back in the check to insure name is not NULL. If we're still at 1+ hours then little bodges like this are nowhere near sufficient and sterner stuff will be needed. Do we actually need the test? My googling turns up zero instances of anyone reporting the "ioremap on RAM pfn" warning. Where's the rest of the time being spent? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86: Optimize resource lookups for ioremap
On 8/27/2014 4:18 PM, Andrew Morton wrote: > On Wed, 27 Aug 2014 16:09:09 -0700 Mike Travis wrote: > >> ... --- linux.orig/kernel/resource.c +++ linux/kernel/resource.c @@ -494,6 +494,43 @@ 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 __weak 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(_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(_lock); + return ret; +} +EXPORT_SYMBOL_GPL(region_is_ram); >>> >>> Exporting a __weak symbol is strange. I guess it works, but neither >>> the __weak nor the export are actually needed? >>> >> >> I mainly used 'weak' and export because that was what the page_is_ram >> function was using. Most likely this won't be used anywhere else but >> I wasn't sure. I can certainly remove the weak and export, at least >> until it's actually needed? > > Several architectures implement custom page_is_ram(), so they need the > __weak. region_is_ram() needs neither so yes, they should be removed. Okay. > > > > Doing strcmp("System RAM") is rather a hack. Is there nothing in > resource.flags which can be used? Or added otherwise? I agree except this mimics the page_is_ram function: while ((res.start < res.end) && (find_next_iomem_res(, "System RAM", true) >= 0)) { So it passes the same literal string which then find_next does the same strcmp on it: if (p->flags != res->flags) continue; if (name && strcmp(p->name, name)) continue; I should add back in the check to insure name is not NULL. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86: Optimize resource lookups for ioremap
On Wed, 27 Aug 2014 16:09:09 -0700 Mike Travis wrote: > > >> > >> ... > >> > >> --- linux.orig/kernel/resource.c > >> +++ linux/kernel/resource.c > >> @@ -494,6 +494,43 @@ 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 __weak 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(_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(_lock); > >> + return ret; > >> +} > >> +EXPORT_SYMBOL_GPL(region_is_ram); > > > > Exporting a __weak symbol is strange. I guess it works, but neither > > the __weak nor the export are actually needed? > > > > I mainly used 'weak' and export because that was what the page_is_ram > function was using. Most likely this won't be used anywhere else but > I wasn't sure. I can certainly remove the weak and export, at least > until it's actually needed? Several architectures implement custom page_is_ram(), so they need the __weak. region_is_ram() needs neither so yes, they should be removed. Doing strcmp("System RAM") is rather a hack. Is there nothing in resource.flags which can be used? Or added otherwise? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86: Optimize resource lookups for ioremap
On 8/27/2014 4:05 PM, Andrew Morton wrote: > On Wed, 27 Aug 2014 17:59:28 -0500 Mike Travis wrote: > >> 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. >> >> ... >> >> --- linux.orig/kernel/resource.c >> +++ linux/kernel/resource.c >> @@ -494,6 +494,43 @@ 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 __weak 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(_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(_lock); >> +return ret; >> +} >> +EXPORT_SYMBOL_GPL(region_is_ram); > > Exporting a __weak symbol is strange. I guess it works, but neither > the __weak nor the export are actually needed? > I mainly used 'weak' and export because that was what the page_is_ram function was using. Most likely this won't be used anywhere else but I wasn't sure. I can certainly remove the weak and export, at least until it's actually needed? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86: Optimize resource lookups for ioremap
On Wed, 27 Aug 2014 17:59:28 -0500 Mike Travis wrote: > 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. > > ... > > --- linux.orig/kernel/resource.c > +++ linux/kernel/resource.c > @@ -494,6 +494,43 @@ 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 __weak 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(_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(_lock); > + return ret; > +} > +EXPORT_SYMBOL_GPL(region_is_ram); Exporting a __weak symbol is strange. I guess it works, but neither the __weak nor the export are actually needed? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86: Optimize resource lookups for ioremap
On Wed, 27 Aug 2014 17:59:28 -0500 Mike Travis tra...@sgi.com wrote: 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. ... --- linux.orig/kernel/resource.c +++ linux/kernel/resource.c @@ -494,6 +494,43 @@ 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 __weak 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; +} +EXPORT_SYMBOL_GPL(region_is_ram); Exporting a __weak symbol is strange. I guess it works, but neither the __weak nor the export are actually needed? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86: Optimize resource lookups for ioremap
On 8/27/2014 4:05 PM, Andrew Morton wrote: On Wed, 27 Aug 2014 17:59:28 -0500 Mike Travis tra...@sgi.com wrote: 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. ... --- linux.orig/kernel/resource.c +++ linux/kernel/resource.c @@ -494,6 +494,43 @@ 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 __weak 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; +} +EXPORT_SYMBOL_GPL(region_is_ram); Exporting a __weak symbol is strange. I guess it works, but neither the __weak nor the export are actually needed? I mainly used 'weak' and export because that was what the page_is_ram function was using. Most likely this won't be used anywhere else but I wasn't sure. I can certainly remove the weak and export, at least until it's actually needed? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86: Optimize resource lookups for ioremap
On Wed, 27 Aug 2014 16:09:09 -0700 Mike Travis tra...@sgi.com wrote: ... --- linux.orig/kernel/resource.c +++ linux/kernel/resource.c @@ -494,6 +494,43 @@ 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 __weak 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; +} +EXPORT_SYMBOL_GPL(region_is_ram); Exporting a __weak symbol is strange. I guess it works, but neither the __weak nor the export are actually needed? I mainly used 'weak' and export because that was what the page_is_ram function was using. Most likely this won't be used anywhere else but I wasn't sure. I can certainly remove the weak and export, at least until it's actually needed? Several architectures implement custom page_is_ram(), so they need the __weak. region_is_ram() needs neither so yes, they should be removed. looks at the code Doing strcmp(System RAM) is rather a hack. Is there nothing in resource.flags which can be used? Or added otherwise? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86: Optimize resource lookups for ioremap
On 8/27/2014 4:18 PM, Andrew Morton wrote: On Wed, 27 Aug 2014 16:09:09 -0700 Mike Travis tra...@sgi.com wrote: ... --- linux.orig/kernel/resource.c +++ linux/kernel/resource.c @@ -494,6 +494,43 @@ 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 __weak 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; +} +EXPORT_SYMBOL_GPL(region_is_ram); Exporting a __weak symbol is strange. I guess it works, but neither the __weak nor the export are actually needed? I mainly used 'weak' and export because that was what the page_is_ram function was using. Most likely this won't be used anywhere else but I wasn't sure. I can certainly remove the weak and export, at least until it's actually needed? Several architectures implement custom page_is_ram(), so they need the __weak. region_is_ram() needs neither so yes, they should be removed. Okay. looks at the code Doing strcmp(System RAM) is rather a hack. Is there nothing in resource.flags which can be used? Or added otherwise? I agree except this mimics the page_is_ram function: while ((res.start res.end) (find_next_iomem_res(res, System RAM, true) = 0)) { So it passes the same literal string which then find_next does the same strcmp on it: if (p-flags != res-flags) continue; if (name strcmp(p-name, name)) continue; I should add back in the check to insure name is not NULL. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86: Optimize resource lookups for ioremap
On Wed, 27 Aug 2014 16:25:24 -0700 Mike Travis tra...@sgi.com wrote: looks at the code Doing strcmp(System RAM) is rather a hack. Is there nothing in resource.flags which can be used? Or added otherwise? I agree except this mimics the page_is_ram function: while ((res.start res.end) (find_next_iomem_res(res, System RAM, true) = 0)) { Yeah. Sigh. So it passes the same literal string which then find_next does the same strcmp on it: if (p-flags != res-flags) continue; if (name strcmp(p-name, name)) continue; I should add back in the check to insure name is not NULL. If we're still at 1+ hours then little bodges like this are nowhere near sufficient and sterner stuff will be needed. Do we actually need the test? My googling turns up zero instances of anyone reporting the ioremap on RAM pfn warning. Where's the rest of the time being spent? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86: Optimize resource lookups for ioremap
On 8/27/2014 4:37 PM, Andrew Morton wrote: On Wed, 27 Aug 2014 16:25:24 -0700 Mike Travis tra...@sgi.com wrote: looks at the code Doing strcmp(System RAM) is rather a hack. Is there nothing in resource.flags which can be used? Or added otherwise? I agree except this mimics the page_is_ram function: while ((res.start res.end) (find_next_iomem_res(res, System RAM, true) = 0)) { Yeah. Sigh. So it passes the same literal string which then find_next does the same strcmp on it: if (p-flags != res-flags) continue; if (name strcmp(p-name, name)) continue; I should add back in the check to insure name is not NULL. If we're still at 1+ hours then little bodges like this are nowhere near sufficient and sterner stuff will be needed. Do we actually need the test? My googling turns up zero instances of anyone reporting the ioremap on RAM pfn warning. We get them more than we like, mostly from 3rd party vendors, and esp. those that merely port their windows drivers to linux. Where's the rest of the time being spent? This device has a huge internal memory and many processing devices. So it loads up an operating system and starts a bunch of pseudo network connections through the PCI-e/driver interface. It was hard to determine what percentage the ioremap played in the overall starting time (based on what info we were able to collect). But the ioremap was definitely the largest part of the 'modprobe' operation. I think realistically that's all we have control over. (But as I mentioned, we are encouraging the vendor to look into starting the devices in parallel. The overlap will cut down the overall time by quite a bit, being there are 31 devices.) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86: Optimize resource lookups for ioremap
On Wed, 27 Aug 2014 16:54:18 -0700 Mike Travis tra...@sgi.com wrote: If we're still at 1+ hours then little bodges like this are nowhere near sufficient and sterner stuff will be needed. Do we actually need the test? My googling turns up zero instances of anyone reporting the ioremap on RAM pfn warning. We get them more than we like, mostly from 3rd party vendors, and esp. those that merely port their windows drivers to linux. Dang. So wrapping the check in CONFIG_DEBUG_VM would be problematic? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/