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:54:18 -0700 [thread overview]
Message-ID: <53FE6FAA.6010806@sgi.com> (raw)
In-Reply-To: <20140827163745.774e9b5c591e8f9cf7542a4d@linux-foundation.org>
On 8/27/2014 4:37 PM, Andrew Morton wrote:
> On Wed, 27 Aug 2014 16:25:24 -0700 Mike Travis <travis@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, 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>
next prev parent reply other threads:[~2014-08-27 23:54 UTC|newest]
Thread overview: 17+ 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 ` [PATCH 1/2] x86: Optimize resource lookups for ioremap Mike Travis
2014-08-27 23:05 ` Andrew Morton
2014-08-27 23:09 ` Mike Travis
2014-08-27 23:18 ` Andrew Morton
2014-08-27 23:25 ` Mike Travis
2014-08-27 23:37 ` Andrew Morton
2014-08-27 23:54 ` Mike Travis [this message]
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 23:06 ` [PATCH 0/2] x86: Speed up ioremap operations Andrew Morton
2014-08-27 23:15 ` Mike Travis
2014-08-27 23:20 ` Andrew Morton
2014-08-27 23:30 ` Mike Travis
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: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
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=53FE6FAA.6010806@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).