From: Mike Travis <travis@sgi.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: mingo@redhat.com, tglx@linutronix.de, hpa@zytor.com,
msalter@redhat.com, dyoung@redhat.com, riel@redhat.com,
peterz@infradead.org, mgorman@suse.de,
linux-kernel@vger.kernel.org, x86@kernel.org, linux-mm@kvack.org,
Alex Thorlton <athorlton@sgi.com>
Subject: Re: [PATCH 1/2] x86: Optimize resource lookups for ioremap
Date: Wed, 27 Aug 2014 16:09:09 -0700 [thread overview]
Message-ID: <53FE6515.6050102@sgi.com> (raw)
In-Reply-To: <20140827160515.c59f1c191fde5f788a7c42f6@linux-foundation.org>
On 8/27/2014 4:05 PM, Andrew Morton wrote:
> On Wed, 27 Aug 2014 17:59:28 -0500 Mike Travis <travis@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, 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>
WARNING: multiple messages have this Message-ID (diff)
From: Mike Travis <travis@sgi.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: mingo@redhat.com, tglx@linutronix.de, hpa@zytor.com,
msalter@redhat.com, dyoung@redhat.com, riel@redhat.com,
peterz@infradead.org, mgorman@suse.de,
linux-kernel@vger.kernel.org, x86@kernel.org, linux-mm@kvack.org,
Alex Thorlton <athorlton@sgi.com>
Subject: Re: [PATCH 1/2] x86: Optimize resource lookups for ioremap
Date: Wed, 27 Aug 2014 16:09:09 -0700 [thread overview]
Message-ID: <53FE6515.6050102@sgi.com> (raw)
In-Reply-To: <20140827160515.c59f1c191fde5f788a7c42f6@linux-foundation.org>
On 8/27/2014 4:05 PM, Andrew Morton wrote:
> On Wed, 27 Aug 2014 17:59:28 -0500 Mike Travis <travis@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?
next prev parent reply other threads:[~2014-08-27 23:09 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-27 22:59 [PATCH 0/2] x86: Speed up ioremap operations Mike Travis
2014-08-27 22:59 ` Mike Travis
2014-08-27 22:59 ` [PATCH 1/2] x86: Optimize resource lookups for ioremap Mike Travis
2014-08-27 22:59 ` Mike Travis
2014-08-27 23:05 ` Andrew Morton
2014-08-27 23:05 ` Andrew Morton
2014-08-27 23:09 ` Mike Travis [this message]
2014-08-27 23:09 ` Mike Travis
2014-08-27 23:18 ` Andrew Morton
2014-08-27 23:18 ` Andrew Morton
2014-08-27 23:25 ` Mike Travis
2014-08-27 23:25 ` Mike Travis
2014-08-27 23:37 ` Andrew Morton
2014-08-27 23:37 ` Andrew Morton
2014-08-27 23:54 ` Mike Travis
2014-08-27 23:54 ` Mike Travis
2014-08-28 0:21 ` Andrew Morton
2014-08-28 0:21 ` Andrew Morton
2014-08-27 22:59 ` [PATCH 2/2] x86: Use optimized ioresource lookup in ioremap function Mike Travis
2014-08-27 22:59 ` Mike Travis
2014-08-27 23:06 ` [PATCH 0/2] x86: Speed up ioremap operations Andrew Morton
2014-08-27 23:06 ` Andrew Morton
2014-08-27 23:15 ` Mike Travis
2014-08-27 23:15 ` Mike Travis
2014-08-27 23:20 ` Andrew Morton
2014-08-27 23:20 ` Andrew Morton
2014-08-27 23:30 ` Mike Travis
2014-08-27 23:30 ` Mike Travis
2014-08-28 6:48 ` Ingo Molnar
2014-08-28 6:48 ` Ingo Molnar
-- strict thread matches above, loose matches on Subject: below --
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 ` Mike Travis
2014-08-29 19:53 [PATCH 0/2] x86: Speed up ioremap operations Mike Travis
2014-08-29 19:53 ` [PATCH 1/2] x86: Optimize resource lookups for ioremap Mike Travis
2014-08-29 19:53 ` Mike Travis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53FE6515.6050102@sgi.com \
--to=travis@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=athorlton@sgi.com \
--cc=dyoung@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=msalter@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.