[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20140827163745.774e9b5c591e8f9cf7542a4d@linux-foundation.org>
Date: Wed, 27 Aug 2014 16:37:45 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Mike Travis <travis@....com>
Cc: mingo@...hat.com, tglx@...utronix.de, hpa@...or.com,
msalter@...hat.com, dyoung@...hat.com, riel@...hat.com,
peterz@...radead.org, mgorman@...e.de,
linux-kernel@...r.kernel.org, x86@...nel.org, linux-mm@...ck.org,
Alex Thorlton <athorlton@....com>
Subject: Re: [PATCH 1/2] x86: Optimize resource lookups for ioremap
On Wed, 27 Aug 2014 16:25:24 -0700 Mike Travis <travis@....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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists