How kernel space is common to all processes

[tushs]

Hi, I am trying to understand how physical and virtual memory space works for kernel space. following is question,
ASSUME,
VIRTUAL MEM: |---kernel code---|---kernel data---|----kernel HEAP----|----kernel stack---|---user stack---|---user heap---|----user data---|--user code---|
ADDRESS 4GB <----- 3GB -----> 0GB
1. Is above ranges valid? I think it is
2. 0-3 GB user space is no doubt individual for each process but 3 to 4 G range (1G) is mess which I want to understand, As per my understanding: kernel stack is per process area, kernel code and kernel data, heap is global across all processes.
now do we need to load new stack each time while context switch. Is it true that we have 1 GB to for housekeeping of all the processes?? If I assume kernel space is somehow managing its vm areas (I mean size of memory required to keep metadata to allocated or mapped regions) where USER space mmap information [metadata] is kept??
I think its unrealistic to keep it in global in kernel space!!
May be this is where U-AREA comes but How to manage dynamically expanding size of uarea per process? I mean for each alloc or mmap there will 2 possibilities that we need per process private area or we need a global area. so is it true that we need to mange all above[its virtual to physical mapping and page dir values]???
How linux do it? I did not found in-depth description on net.

[gerryg400]

How linux do it? I did not found in-depth description on net.

Search for "Understanding the Linux Virtual Memory Manager" by Gorman. It has all information about the Linux memory managers.

[tushs]

I am reading link, But can somebody answer my questions please? It will help me to get clear picture how kernel/process layout should be rather then what data structures are used by linux.
Which virtual address space is currently used by process (user mode) is different for each process, but memory/virtual address space needed to keep this info in kernel mode should be reserved per process. I mean kernel address space can not be global or exactly same for all processes is this right?

[rdos]

It depends on you design. There is nothing that forces you to reserve 1G for kernel, and 3G for applications. It's up to your own needs. I reserve 512MB for kernel, with the biggest areas being 128MB for a dword aligned kernel memory allocator, and 320MB for a page aligned kernel memory allocator. 16MB is reserved for the kernel and its device-drivers, and the rest is for some other features (like mapping page-tables).

When it comes to kernel stacks, those are required for ring 0. I allocate those from the kernel memory pool as needed.

[tushs]

Let me re-frame my question, suppose some scattered memory of user space 0 to 3 GB is currently in used. Now I need to keep information of this scattered area [start offset ,end offset, physical page address etc] this information is that process specific and when kernel is running in context of that process this information is valid.
For different process this metadata is no more valid or at least I need to change physical page address in PG DIR and PG TABLE for that range where this process specific metadata is kept. Is this true? How you are managing this in your os?

[Combuster]

You only need to change CR3.

[rdos]

You need a memory block in kernel-space which describes your process, including the setting of CR3. I allocate this from the kernel memory pool. You would also likely need a similar memory block per-thread, that also would be allocated in kernel memory space.

[gerryg400]

Like rdos said, you need to keep the structures that describe each memory space in the MM. Unlike the page tables, the structures are small so they can be in permanently allocated common kernel/MM memory.

I treat the allocation of virtual memory within the context and the allocation of physical memory separately. The only information about physical memory I have is the CR3. When a mapping is added to a context you don't need to allocate physical memory yet, you can wait until a fault occurs as long as the mapping structure contains enough information to know how to add the physical memory. (e.g. is it copy-on-write, load-from-file etc.)

I have a structure that describes each memory context, one per process like this

Code: Select all

struct mm_context {
    void    *cr3;
    klist_t mapping_list;
    int     flags;
    void    *low_addr; /* The lowest address in this context */
    void    *hi_addr;  /* The highest address + 1 in the context */
    void    *anon_addr; /* Anonymous mappings are done above this address */
};

Each time the process allocates memory I add or extend a mapping in the mapping list. The mappings look like this.

Code: Select all

struct mm_mapping {
    klist_chain_t mapchain;  /* This is 2 pointers == 16 bytes */
    void          *start_addr;
    size_t        length;
    int           flags;
    int           fd; /* if it's an mmaped file */
};

My mm is a process and these structures appear in mm space and are allocated and freed there with malloc and free. As you can see my MM is very simple and I'm still adding features.

[gravaera]

Yo:

The kernel is like a huge shared library with functions that all processes need to use in order to function. If a process needs more memory, it must ask the kernel. If a process needs access to hardware (disk, network, etc), it must also ask the kernel. If a process needs to start another process, it must also call a kernel function to get this done.

Most kernels accomplish this by allowing the userspace thread to enter and execute the kernel's code. This can be done in one of two main ways:

1. Have the kernel in its own address space separate from all processes, and have processes call into the kernel by initiating a fast address space switch, and then switch back when this is complete.
2. Have the kernel mapped into every process's address space as a sort of "shared library" so to speak, and in so doing, the processes execute kernel functions by entering the kernel's "high" address space.

Most kernels use method #2 because it has performance benefits. The amount of space needed for the kernel when you use #2 is dependent on how "heavy duty" or resource heavy your kernel is. Most new devs go with 1GB because it's a stable enough figure, and Linux uses that amount without any problems. Additionally, the kernel is not necessarily split into strictly defined segments, like code, data, heap, etc. Whether or not you create hard borders between these parts of the kernel is up to you. It would just be a result of how you designed your MM. The information on processes, etc would be stored in this high address space portion with the kernel.

[tushs]

Interesting !!
I got the point its mapping new page dir and keeping kernel (shared lib ) common to all processes with its code data and heap common to all.

"The information on processes, etc would be stored in this high address space portion with the kernel."

You mean for each process in high address space, ZONE_HIGHMEM above 896 MB? Anyways, as you said its implementers choice
Many thanks to all of you.

[gravaera]

Yo: I think it would be best if you avoided binding your understanding of kernel concepts to the linux kernel -- it will be better for you overall in the end

Read generally, and write down notes about possible designs. Then go and read concrete examples, such as linux source code and research papers to understand how current hardware constrains you to have to implement your designs; don't do it the other way around by reading concrete examples first. Use the linux source after you have read at a conceptual level.

--Peace out,
gravaera