[PATCH 1/2] ARM: calculate VMALLOC_END by probing inmdesc->map_io()

Santosh Shilimkar santosh.shilimkar at ti.com
Sun Jan 23 09:27:23 EST 2011


> -----Original Message-----
> From: Nicolas Pitre [mailto:nico at fluxnic.net]
> Sent: Sunday, January 23, 2011 7:48 PM
> To: Santosh Shilimkar
> Cc: Eric Miao; Russell King - ARM Linux; linux-arm-
> kernel at lists.infradead.org
> Subject: RE: [PATCH 1/2] ARM: calculate VMALLOC_END by probing
> inmdesc->map_io()
>
[...]

> > > Can we possibly get away with a global VMALLOC_END?  What if we
> were
> > > to
> > > decide it is fixed at 0xf0000000 for everyone?
> > >
> > Which would potentialy shrink the lowmem and vmalloc area. With
> > current flexibility of adjustable VMALLOC_END, in 1G:3G model,
> > we managed to  have almost ~ 896 MB virtual space available
> > for lowmem + vmalloc. So keeping 128MB for vmalloc ~768MB of
> > memory can be directly addressable without highmem support.
>
> OK, I just wanted to see if people do think that the simplicity of a
> global definition would have made the per-architecture flexibility
> irrelevant.  But looking at some of the mappings it seems that quite
> a
> lot of virtual space wastage would be imposed in some cases.
>
Yep.

> Plus, moving vmalloc_end to the machine record is almost as simple
> while
> preserving the current flexibility.
>
As long we can maintain current flexibility, there shouldn't be
any problem.

Regards,
Santosh



More information about the linux-arm-kernel mailing list