Mainline OMAP3 breakage (and other OMAP?)

[Russell King - ARM Linux]

On Fri, Dec 03, 2010 at 02:10:23PM +0200, Felipe Contreras wrote:
> On Fri, Dec 3, 2010 at 10:41 AM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > On Fri, Dec 03, 2010 at 12:09:55PM +0900, Paul Mundt wrote:
> >> This has been fixed since -rc2.
> >
> > So it is.  However, the ioremap fix is wrong.
> >
> >        } else {
> >                paddr = memblock_alloc(size, PAGE_SIZE);
> >        }
> >
> >        memblock_free(paddr, size);
> >        memblock_remove(paddr, size);
> >
> > Didn't I say that such blocks were supposed to be aligned to a 2MB
> > boundary - and the size also so aligned?
> 
> I asked you if there was something special and I didn't receive any response:
> http://article.gmane.org/gmane.linux.kernel/1048434

So you thought you could ride rough-shod over my statement and ignore it?
Thank you for treating me like shit, I'll remember that for future and
treat you in a similar manner.

> So, why SZ_2M?

Firstly, that's the granularity which we allocate page tables - one
Linux page table covers 2MB of memory.  We want to avoid creating page
tables for the main memory mapping as that increases TLB pressure through
the use of additional TLB entries, and more page table walks.

Plus, we never used to allow the kernel's direct memory mapping to be
mapped at anything less than section size - this restriction has since
been lifted due to OMAP SRAM problems, but I'd rather we stuck with it
to ensure that we have proper behaviour from all parts of the system.

Secondly, we don't want to end up with lots of fragmentation at the end
of the memory mapping as that'll reduce performance, not only by making
the pfn_valid() search more expensive.

Emsuring a minimum allocation size and alignment makes sure that the
regions can be coalesced together into one block, and minimises run-time
expenses.

So please, 2MB, or if you object, at the _very_ _least_ 1MB.  But
definitely not PAGE_SIZE.