Mapping of ZONE_HIGHMEM in kernel address space in 32bit x86

[12]

Well, I came up with the same question: Why 896MB (almost all the linear space) is permanently mapped linearly to physical memory? The alternative would be to map just the amount that accounts to the kernel image and the uninitialized data, and then dinamically map the rest. I'd guess that the tradeoff is better performance in most cases, at the cost of flexibility in the mappings, because little space is left to map potentially enormous amounts of physical memory.

El 14/05/2013, a las 0:45, Paul Davies C <pauldaviesc at gmail.com> escribió:

> It is an arbitrary question that popped in my mind. However, I came to know that the constraints I stated in the previous mail is only restricted to x86 only.Now besides my first questions , I have one more question, Why x86 only?
> 
> 
> On Tue, May 14, 2013 at 2:34 AM, Sergio Andrés Gómez del Real <sergio.g.delreal at gmail.com> wrote:
>> Sure, I forgot what you said; precisely the mechanism allows to use
>> lots of linear space without necessarily allocating physical memory
>> (demand paging and the like).
>> What about the rest of what I said? Is it correct or is there
>> something wrong about it?
>> Thanks.
>> 
>> On 5/13/13, Valdis.Kletnieks at vt.edu <Valdis.Kletnieks at vt.edu> wrote:
>> > On Mon, 13 May 2013 14:11:22 -0500, Sergio Andr said:
>> >
>> >> 2. When user applications allocates memory, the kernel must allocate
>> >> virtual memory and physical memory, right?
>> >
>> > Wrong. If userspace allocates (say) 15M of memory, the kernel has every
>> > right
>> > to overcommit and not actually allocate either physical memory or backing
>> > page
>> > space for all 15M.  It instead maps it as a non-existent virtual address,
>> > and
>> > if/when the application actually touches the page, it generates a page
>> > fault,
>> > and *then* the kernel does the allocating of physical memory and maybe swap
>> > space.
>> >
>> >
> 
> 
> 
> -- 
> Regards,
> Paul Davies C
> vivafoss.blogspot.com
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130514/30fb76e8/attachment.html