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/
