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:25:24 -0700 [thread overview]
Message-ID: <53FE68E4.4090902@sgi.com> (raw)
In-Reply-To: <20140827161854.0619a04653b336d3adc755f3@linux-foundation.org>
On 8/27/2014 4:18 PM, Andrew Morton wrote:
> On Wed, 27 Aug 2014 16:09:09 -0700 Mike Travis <travis@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, 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:25:24 -0700 [thread overview]
Message-ID: <53FE68E4.4090902@sgi.com> (raw)
In-Reply-To: <20140827161854.0619a04653b336d3adc755f3@linux-foundation.org>
On 8/27/2014 4:18 PM, Andrew Morton wrote:
> On Wed, 27 Aug 2014 16:09:09 -0700 Mike Travis <travis@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.
next prev parent reply other threads:[~2014-08-27 23:25 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
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 [this message]
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=53FE68E4.4090902@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.