Re: [PATCH 1/2] x86: Optimize resource lookups for ioremap

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 8/27/2014 4:37 PM, Andrew Morton wrote:
> On Wed, 27 Aug 2014 16:25:24 -0700 Mike Travis <travis@xxxxxxx> 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@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]