The kernel maintains a free list of pages that are free in physical memory. I
was wondering, are these pages in the kernel space ? They are not mapped to
any of the user address space for sure, so will they be in the kernel memory
?
Thanks
--
View this message in context: http://www.nabble.com/Kernel-vs-user-memory-tp21512362p21512362.html
Sent from the linux-kernel mailing list archive at Nabble.com.
On Fri, Jan 16, 2009 at 9:56 PM, sidc7 <[email protected]> wrote:
>
> The kernel maintains a free list of pages that are free in physical memory. I
> was wondering, are these pages in the kernel space ? They are not mapped to
> any of the user address space for sure, so will they be in the kernel memory
> ?
Of course. Note that much of user address space is also mapped into
kernel address space (all of it, in fact, unless you're on a 32-bit
x86 system with PAE and more than 3G or so of RAM), so such a clear
division isn't quite that easy :)
All the gory details are in mm/page_alloc.c and mm/slab.c (or slub.c
or slob.c, depending on your build configuration).
I am not an expert, just started doing some kernel programming and code
reading, so as far as I understand, memory can be either mapped to user
space or kernel space, if its neither in user and kernel, as you said, the
division is not easy, where will the memory be mapped to, is there any other
special region ?
Thanks
Bryan Donlan wrote:
>
> On Fri, Jan 16, 2009 at 9:56 PM, sidc7 <[email protected]>
> wrote:
>>
>> The kernel maintains a free list of pages that are free in physical
>> memory. I
>> was wondering, are these pages in the kernel space ? They are not mapped
>> to
>> any of the user address space for sure, so will they be in the kernel
>> memory
>> ?
>
> Of course. Note that much of user address space is also mapped into
> kernel address space (all of it, in fact, unless you're on a 32-bit
> x86 system with PAE and more than 3G or so of RAM), so such a clear
> division isn't quite that easy :)
>
> All the gory details are in mm/page_alloc.c and mm/slab.c (or slub.c
> or slob.c, depending on your build configuration).
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
View this message in context: http://www.nabble.com/Kernel-vs-user-memory-tp21512362p21512985.html
Sent from the linux-kernel mailing list archive at Nabble.com.
On Fri, Jan 16, 2009 at 11:21 PM, sidc7 <[email protected]> wrote:
>
> I am not an expert, just started doing some kernel programming and code
> reading, so as far as I understand, memory can be either mapped to user
> space or kernel space, if its neither in user and kernel, as you said, the
> division is not easy, where will the memory be mapped to, is there any other
> special region ?
For each memory space (usually one per process), the kernel sets up a
page table. The lower PAGE_OFFSET bytes are mapped differently for
each such space, but above the address PAGE_OFFSET, every process has
the same mappings - this is what one usually thinks of when one hears
'kernel memory'. The kernel then puts its data structures in this
upper area, so that the addresses of these structures remains the same
in all processes. Of course, these pages are only accessible in kernel
mode - attempting to access them at all from a user process will get
you a segmentation fault.
Note also that while on 64-bit platforms the kernel memory map
generally includes all of physical RAM, on 32-bit platforms such as
the x86, there's typically only about 700mb of physical RAM mapped in
this area by default; the remainder of RAM (if any) can only be used
for page/buffer cache and process memory.
sidc7 wrote:
> The kernel maintains a free list of pages that are free in physical memory. I
> was wondering, are these pages in the kernel space ? They are not mapped to
> any of the user address space for sure, so will they be in the kernel memory
> ?
On a non-highmem kernel, they will be -- ALL memory is mapped in kernel
space on non-highmem kernels. For highmem kernels, they will generally
not be mapped at all, unless they are lowmem pages.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
If I am not mistaken, Linux kernel is a high memory kernel, hence for Linux
kernel, nothing will be mapped to the kernel space, other than the memory
beyond 896MB which is the kernel's virtual address space. Am I right on
this?
Thanks
H. Peter Anvin wrote:
>
> sidc7 wrote:
>> The kernel maintains a free list of pages that are free in physical
>> memory. I
>> was wondering, are these pages in the kernel space ? They are not mapped
>> to
>> any of the user address space for sure, so will they be in the kernel
>> memory
>> ?
>
> On a non-highmem kernel, they will be -- ALL memory is mapped in kernel
> space on non-highmem kernels. For highmem kernels, they will generally
> not be mapped at all, unless they are lowmem pages.
>
> -hpa
>
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel. I don't speak on their behalf.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
View this message in context: http://www.nabble.com/Kernel-vs-user-memory-tp21512362p21513615.html
Sent from the linux-kernel mailing list archive at Nabble.com.
sidc7 wrote:
> If I am not mistaken, Linux kernel is a high memory kernel, hence for Linux
> kernel, nothing will be mapped to the kernel space, other than the memory
> beyond 896MB which is the kernel's virtual address space. Am I right on
> this?
It's a compilation option, and depends on the architecture. What you
described is true for an i386 kernel compiled as a highmem kernel. On
the other hand, a 64 bit kernel is *never* highmem.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
One last question, which one of the two lowmem or highmem kernel is most
commonly used on contemporary linux boxes. I am guessing highmem kernel ?
Thanks for the quick replies, helped a lot
H. Peter Anvin wrote:
>
> sidc7 wrote:
>> If I am not mistaken, Linux kernel is a high memory kernel, hence for
>> Linux
>> kernel, nothing will be mapped to the kernel space, other than the memory
>> beyond 896MB which is the kernel's virtual address space. Am I right on
>> this?
>
> It's a compilation option, and depends on the architecture. What you
> described is true for an i386 kernel compiled as a highmem kernel. On
> the other hand, a 64 bit kernel is *never* highmem.
>
> -hpa
>
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel. I don't speak on their behalf.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
View this message in context: http://www.nabble.com/Kernel-vs-user-memory-tp21512362p21513643.html
Sent from the linux-kernel mailing list archive at Nabble.com.
sidc7 wrote:
> One last question, which one of the two lowmem or highmem kernel is most
> commonly used on contemporary linux boxes. I am guessing highmem kernel ?
>
> Thanks for the quick replies, helped a lot
For PCs, 32 bit is generally highmem, and 64 bits is lowmem. Most
embedded systems are lowmem.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
Thanks for the help, makes things a lot clearer
H. Peter Anvin wrote:
>
> sidc7 wrote:
>> One last question, which one of the two lowmem or highmem kernel is most
>> commonly used on contemporary linux boxes. I am guessing highmem kernel ?
>>
>> Thanks for the quick replies, helped a lot
>
> For PCs, 32 bit is generally highmem, and 64 bits is lowmem. Most
> embedded systems are lowmem.
>
> -hpa
>
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel. I don't speak on their behalf.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
View this message in context: http://www.nabble.com/Kernel-vs-user-memory-tp21512362p21550460.html
Sent from the linux-kernel mailing list archive at Nabble.com.