Mapping of ZONE_HIGHMEM in kernel address space in 32bit x86

Mapping of ZONE_HIGHMEM in kernel address space in 32bit x86

[Paul Davies C]

In a system with 3:1 split, the ZONE_NORMAL with a size of 896MB is
permanently mapped to the kernel address space.This leaves a 128MB free
space in the Kernel address space and according to my understanding, the
ZONE_HIGHMEM pages are mapped temporarily to this 128MB part. If the system
actually had a 4GB physical memory you will be mapping(not smultaneously)
the HIHGMEM part- which is roughly 3.2GB - to this 128MB part. If that was
the case Kernel would have to frequently access HIHGMEM which implicates a
frequent change in temporaty mapping and that in my view is a penalty. So
what was the reason why ZONE_NORMAL fixed at 896MB and not something really
lower?

-- 
*Regards,*
*Paul Davies C*
vivafoss.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130511/78273717/attachment.html 

Mapping of ZONE_HIGHMEM in kernel address space in 32bit x86

[Prabhu nath]

Is this is a question that popped up to your mind arbitrarily or do you
have a specific system at hand which triggered you to ponder over the
design of the kernel ? I felt the answer to this question is not straight
forward but is multi faceted and to be discussed in a specific context.


On Sat, May 11, 2013 at 9:02 AM, Paul Davies C <pauldaviesc@gmail.com>wrote:

>
> In a system with 3:1 split, the ZONE_NORMAL with a size of 896MB is
> permanently mapped to the kernel address space.This leaves a 128MB free
> space in the Kernel address space and according to my understanding, the
> ZONE_HIGHMEM pages are mapped temporarily to this 128MB part. If the system
> actually had a 4GB physical memory you will be mapping(not smultaneously)
> the HIHGMEM part- which is roughly 3.2GB - to this 128MB part. If that was
> the case Kernel would have to frequently access HIHGMEM which implicates a
> frequent change in temporaty mapping and that in my view is a penalty. So
> what was the reason why ZONE_NORMAL fixed at 896MB and not something really
> lower?
>
> --
> *Regards,*
> *Paul Davies C*
> vivafoss.blogspot.com
>
>
-- 
Regards,
Prabhunath G
Linux Trainer
Bangalore
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130513/d0636acd/attachment.html 

Mapping of ZONE_HIGHMEM in kernel address space in 32bit x86

[Sergio Andrés Gómez del Real]

I've got some questions regarding this linear to physical address
mapping on x86 architecture; I'm not sure I've grassped the whole
thing.
Before asking, I'd like to be sure I understand some basic things about this:

1. Addresses within the kernel are linked to start at 0xC0000000 so,
that the kernel issues linear addresses starting at gigabyte 3 is
really accomplished at link time through a linker directive.
2. User applications are linked to addresses somewhere at 0x00000000-0xBFFFFFFF.
3. There is a data structure (struct page), immediately following the
kernel image in physical memory. It describes all page frames
available.
4. The kernel creates its own page-relative structures. It maps linear
addresses starting at 0xC0000000 linearly starting at physical address
0x00000000. So, accessing this linear space is equivalent to accessing
physical memory, because the map is linear and the conversion between
linear to physical address is always a constant (0xC0000000)?
5. The last part of the kernel's linear address space is reserved for
temporarily mapping high memory (is this strictly true?).

If all of this is true, here are my questions:

1. The problem of accessing high memory is EXCLUSIVE to the kernel,
right? It doesn't affect user-space applications, because it's linear
address, 0x00000000-0xBFFFFFFF, can be mapped anywhere in physical
memory, by just writing the high-memory address to the appropiate page
tables. Is this right?
2. When user applications allocates memory, the kernel must allocate
virtual memory and physical memory, right? For example, the kernel
would first allocate some linear address from the processes' address
space, and then find some suitable page frames where to map this
linear address. It would just write to the appropiate page tables;
specifically, the page frames can come from low memory or high memory,
i.e the high memory problem does not affect user-space physical memory
allocations. Is this entirely correct?
3. Is physical memory allocated to user-space generally satisfied from
high memory?
4. When does the kernel allocate pages from high memory to itself?

Thanks in advance to anyone who replies.

On 5/13/13, Prabhu nath <gprabhunath@gmail.com> wrote:
> Is this is a question that popped up to your mind arbitrarily or do you
> have a specific system at hand which triggered you to ponder over the
> design of the kernel ? I felt the answer to this question is not straight
> forward but is multi faceted and to be discussed in a specific context.
>
>
> On Sat, May 11, 2013 at 9:02 AM, Paul Davies C
> <pauldaviesc@gmail.com>wrote:
>
>>
>> In a system with 3:1 split, the ZONE_NORMAL with a size of 896MB is
>> permanently mapped to the kernel address space.This leaves a 128MB free
>> space in the Kernel address space and according to my understanding, the
>> ZONE_HIGHMEM pages are mapped temporarily to this 128MB part. If the
>> system
>> actually had a 4GB physical memory you will be mapping(not smultaneously)
>> the HIHGMEM part- which is roughly 3.2GB - to this 128MB part. If that
>> was
>> the case Kernel would have to frequently access HIHGMEM which implicates
>> a
>> frequent change in temporaty mapping and that in my view is a penalty. So
>> what was the reason why ZONE_NORMAL fixed at 896MB and not something
>> really
>> lower?
>>
>> --
>> *Regards,*
>> *Paul Davies C*
>> vivafoss.blogspot.com
>>
>>
> --
> Regards,
> Prabhunath G
> Linux Trainer
> Bangalore
>

Mapping of ZONE_HIGHMEM in kernel address space in 32bit x86

[Valdis.Kletnieks at vt.edu]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130513/214fef66/attachment.bin 

Mapping of ZONE_HIGHMEM in kernel address space in 32bit x86

[Sergio Andrés Gómez del Real]

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@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.
>
>

Mapping of ZONE_HIGHMEM in kernel address space in 32bit x86

[Paul Davies C]

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@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@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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130514/c5af14e1/attachment.html 

Mapping of ZONE_HIGHMEM in kernel address space in 32bit x86

[Paul Davies C]

Sergio,
        I will try to answer some questions with my limited knowledge. I
hope experts will clarify if there are any misconceptions in my
understanding.


On Tue, May 14, 2013 at 12:41 AM, Sergio Andr?s G?mez del Real <
sergio.g.delreal@gmail.com> wrote:

> I've got some questions regarding this linear to physical address
> mapping on x86 architecture; I'm not sure I've grassped the whole
> thing.
> Before asking, I'd like to be sure I understand some basic things about
> this:
>
> 1. Addresses within the kernel are linked to start at 0xC0000000 so,
> that the kernel issues linear addresses starting at gigabyte 3 is
> really accomplished at link time through a linker directive.
> 2. User applications are linked to addresses somewhere at
> 0x00000000-0xBFFFFFFF.
> 3. There is a data structure (struct page), immediately following the
> kernel image in physical memory. It describes all page frames
> available.
> 4. The kernel creates its own page-relative structures. It maps linear
> addresses starting at 0xC0000000 linearly starting at physical address
> 0x00000000. So, accessing this linear space is equivalent to accessing
> physical memory, because the map is linear and the conversion between
> linear to physical address is always a constant (0xC0000000)?
> 5. The last part of the kernel's linear address space is reserved for
> temporarily mapping high memory (is this strictly true?).
>
> If all of this is true, here are my questions:
>
> 1. The problem of accessing high memory is EXCLUSIVE to the kernel,
> right? It doesn't affect user-space applications, because it's linear
> address, 0x00000000-0xBFFFFFFF, can be mapped anywhere in physical
> memory, by just writing the high-memory address to the appropiate page
> tables. Is this right?
>

Yeah. Its exclusive to the kernel. Consider that we have a 32 bit system
with 4GB physical memory and we have a 3:1 split. Kernel must be able to
access all the physical memory-4GB-but it has only 1GB of virtual address
space. User process's on the other hand can only access maximum 3GB
(hypothetical) of physical memory and has an virtual address space of 3GB
of size.  Now coming back to the problem of the Kernel, very old kernels
made use of static mapping to the address space. So with 1GB of address
space, they could only access 1GB of physical memory. The solution the
Kernel developers  found was to use dynamic mappings. That is use some area
in the Kernel virtual addresses to dynamically map to  higher memory.

2. When user applications allocates memory, the kernel must allocate
> virtual memory and physical memory, right? For example, the kernel
> would first allocate some linear address from the processes' address
> space, and then find some suitable page frames where to map this
> linear address. It would just write to the appropiate page tables;
> specifically, the page frames can come from low memory or high memory,
> i.e the high memory problem does not affect user-space physical memory
> allocations. Is this entirely correct?
> 3. Is physical memory allocated to user-space generally satisfied from
> high memory?
>

In a system with  an installed physical memory of 896 MB does not have any
high memory(Applicable to x86 systems only). So I feel that assumption is
wrong.

4. When does the kernel allocate pages from high memory to itself?
>
> Thanks in advance to anyone who replies.
>
> On 5/13/13, Prabhu nath <gprabhunath@gmail.com> wrote:
> > Is this is a question that popped up to your mind arbitrarily or do you
> > have a specific system at hand which triggered you to ponder over the
> > design of the kernel ? I felt the answer to this question is not straight
> > forward but is multi faceted and to be discussed in a specific context.
> >
> >
> > On Sat, May 11, 2013 at 9:02 AM, Paul Davies C
> > <pauldaviesc@gmail.com>wrote:
> >
> >>
> >> In a system with 3:1 split, the ZONE_NORMAL with a size of 896MB is
> >> permanently mapped to the kernel address space.This leaves a 128MB free
> >> space in the Kernel address space and according to my understanding, the
> >> ZONE_HIGHMEM pages are mapped temporarily to this 128MB part. If the
> >> system
> >> actually had a 4GB physical memory you will be mapping(not
> smultaneously)
> >> the HIHGMEM part- which is roughly 3.2GB - to this 128MB part. If that
> >> was
> >> the case Kernel would have to frequently access HIHGMEM which implicates
> >> a
> >> frequent change in temporaty mapping and that in my view is a penalty.
> So
> >> what was the reason why ZONE_NORMAL fixed at 896MB and not something
> >> really
> >> lower?
> >>
> >> --
> >> *Regards,*
> >> *Paul Davies C*
> >> vivafoss.blogspot.com
> >>
> >>
> > --
> > Regards,
> > Prabhunath G
> > Linux Trainer
> > Bangalore
> >
>



-- 
*Regards,*
*Paul Davies C*
vivafoss.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130514/bf09db31/attachment.html 

Mapping of ZONE_HIGHMEM in kernel address space in 32bit x86

[Arun KS]

Hi Sergio,

On Tue, May 14, 2013 at 12:41 AM, Sergio Andr?s G?mez del Real <
sergio.g.delreal@gmail.com> wrote:

> I've got some questions regarding this linear to physical address
> mapping on x86 architecture; I'm not sure I've grassped the whole
> thing.
> Before asking, I'd like to be sure I understand some basic things about
> this:
>
> 1. Addresses within the kernel are linked to start at 0xC0000000 so,
> that the kernel issues linear addresses starting at gigabyte 3 is
> really accomplished at link time through a linker directive.
> 2. User applications are linked to addresses somewhere at
> 0x00000000-0xBFFFFFFF.
> 3. There is a data structure (struct page), immediately following the
> kernel image in physical memory. It describes all page frames
> available.
> 4. The kernel creates its own page-relative structures. It maps linear
> addresses starting at 0xC0000000 linearly starting at physical address
> 0x00000000. So, accessing this linear space is equivalent to accessing
>

Physical address may not be always 0x0000_0000. It can be mapped any where.


> physical memory, because the map is linear and the conversion between
> linear to physical address is always a constant (0xC0000000)?
> 5. The last part of the kernel's linear address space is reserved for
> temporarily mapping high memory (is this strictly true?).
>
> If all of this is true, here are my questions:
>
> 1. The problem of accessing high memory is EXCLUSIVE to the kernel,
> right? It doesn't affect user-space applications, because it's linear
> address, 0x00000000-0xBFFFFFFF, can be mapped anywhere in physical
> memory, by just writing the high-memory address to the appropiate page
> tables. Is this right?
> 2. When user applications allocates memory, the kernel must allocate
> virtual memory and physical memory, right? For example, the kernel
> would first allocate some linear address from the processes' address
> space, and then find some suitable page frames where to map this
> linear address. It would just write to the appropiate page tables;
> specifically, the page frames can come from low memory or high memory,
> i.e the high memory problem does not affect user-space physical memory
> allocations. Is this entirely correct?
> 3. Is physical memory allocated to user-space generally satisfied from
> high memory?
>
Yes. High mem is the first priority.

thanks,
Arun


> 4. When does the kernel allocate pages from high memory to itself?
>
> Thanks in advance to anyone who replies.
>
> On 5/13/13, Prabhu nath <gprabhunath@gmail.com> wrote:
> > Is this is a question that popped up to your mind arbitrarily or do you
> > have a specific system at hand which triggered you to ponder over the
> > design of the kernel ? I felt the answer to this question is not straight
> > forward but is multi faceted and to be discussed in a specific context.
> >
> >
> > On Sat, May 11, 2013 at 9:02 AM, Paul Davies C
> > <pauldaviesc@gmail.com>wrote:
> >
> >>
> >> In a system with 3:1 split, the ZONE_NORMAL with a size of 896MB is
> >> permanently mapped to the kernel address space.This leaves a 128MB free
> >> space in the Kernel address space and according to my understanding, the
> >> ZONE_HIGHMEM pages are mapped temporarily to this 128MB part. If the
> >> system
> >> actually had a 4GB physical memory you will be mapping(not
> smultaneously)
> >> the HIHGMEM part- which is roughly 3.2GB - to this 128MB part. If that
> >> was
> >> the case Kernel would have to frequently access HIHGMEM which implicates
> >> a
> >> frequent change in temporaty mapping and that in my view is a penalty.
> So
> >> what was the reason why ZONE_NORMAL fixed at 896MB and not something
> >> really
> >> lower?
> >>
> >> --
> >> *Regards,*
> >> *Paul Davies C*
> >> vivafoss.blogspot.com
> >>
> >>
> > --
> > Regards,
> > Prabhunath G
> > Linux Trainer
> > Bangalore
> >
>
> _______________________________________________
> 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/6c776d18/attachment.html 

Mapping of ZONE_HIGHMEM in kernel address space in 32bit x86

[Valdis.Kletnieks at vt.edu]

On Tue, 14 May 2013 11:15:35 +0530, Paul Davies C said:

> 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?

It's architecture dependent.  X86 has a lot of legacy crap that most other
archs never had to deal with (for instance, I/O controllers that could only do
DMA under the 16M line because they only supported 24 address lines). Most
other archs have either been design stable (for example alpha), or they did it
mostly right the first time.  X86 is the only major arch that's really grown
from 16 bit to 32 to 64, accumulating cruft all the way.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130514/83530154/attachment.bin 

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@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@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@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 

Mapping of ZONE_HIGHMEM in kernel address space in 32bit x86

[Valdis.Kletnieks at vt.edu]

On Tue, 14 May 2013 12:25:33 -0500, 12 said:

> s 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.

If most of the memory is used to map lots and lots of 1-2G userspace processes,
this isn't actually a problem.

Anyhow, it's *long* been known that if you have much more than 4G of RAM,
you should just run an x86_64 kernel that doesn't have the 896M problem
instead of trying to use PAE to do it.  The number of boxes out there that
have over 4G of RAM and don't do 64-bit is small, and dropping.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130514/9c66ea25/attachment-0001.bin