Changes between Version 62 and Version 63 of replication_distribution


Ignore:
Timestamp:
Dec 20, 2019, 12:23:35 PM (4 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • replication_distribution

    v62 v63  
    135135
    136136Any thread entering the kernel to execute a system call needs a kernel stack, that must be in the kernel land.
    137 This requires to implement in kernel land as many kernel stacks as the total number of threads (user threads + dedicated kernel threads) in the system.
     137This requires as many kernel stacks as the total number of threads (user threads + dedicated kernel threads) in the system.
    138138For each thread, almos-mkh implements the kernel stack in the 16 Kbytes thread descriptor, that is dynamically allocated in the KHEAP segment, when the thread is created.
    139139Therefore, there is no specific KSTACK segment type for the kernel stacks.
    … …  
    168168The TSAR architecture uses 32 bits cores, to reduce the power consumption.
    169169This creates a big problem to access the remote KDATA and KHEAP segments : with 1 Gbytes of physical memory per cluster, and 256 cluster, the total physical space covered by the N KHEAP segments is 256 Gbytes. This is much larger than the 4 Gbytes virtual space addressable by a 32 bits virtual address.
    170 The consequence is very simple:  we cannot use the MIPS_32 MMU to make the virtual to physical address translation to access the KDATA and KHEAP segments.
     170The consequence is very simple:  we cannot use the MIPS_32 MMU to make the virtual to physical address translation when a thread wants to access a remote KDATA or KHEAP segment.
    171171
    172172But the TSAR architecture provides two useful features to simplify the traduction from an extended pointer XPTR(cxy,ptr) to a 40 bits physical address :
    1731731. The TSAR 40 bits physical address has a specific format : it is the concaténation of an 8 bits CXY field, and a 32 bits LPADDR field, where the CXY defines
    174174the cluster identifier, and the LPADDR is the local physical address inside the cluster.
    175 1. the MIPS32 core used BY the TSAR architecture defines, besides the standard MMU, another non-standard,hardware mechanism for address translation : A 40  bits physical address is simply build by appending to each 32 bits virtual address a 8 bits extension contained in a software controllable register, called DATA_PADDR_EXT.
     1751. the MIPS32 core used BY the TSAR architecture defines, besides the standard MMU, another - non-standard - hardware mechanism for address translation : A 40  bits physical address is simply build by appending to each 32 bits virtual address a 8 bits extension contained in a software controllable register, called DATA_PADDR_EXT.
    176176
    177177In the TSAR architecture, and for any process P in any cluster K, almost-mkh registers only one extra KCODE vseg in the VMM[P,K), because almos-mkh uses the INST-MMU for instruction addresses translation, but does NOT not use the DATA-MMU for data addresses translation : When a core enters the kernel, the DATA-MMU is deactivated, and it is only reactivated when the core returns to user code.
    … …  
    198198
    199199It contains the ''kcode'' vseg (type KCODE), that must be mapped in all user processes.
    200 It is located in the lower part of the virtual space, and starts a address 0. Its size cannot be less than a big page size (2 Mbytes for the TSAR architecture), because it will be mapped as one (or several big) pages.
     200It is located in the lower part of the virtual space, and starts a address 0. Its size cannot be less than a big page size (2 Mbytes for the TSAR architecture), because it will be mapped as one (or several) big pages in the GPT.
    201201 
    202202'''5.1.2 The ''utils'' zone'''
    … …  
    208208'''5.1.3 The ''elf'' zone'''
    209209
    210 It contains the ''text'' (CODE type) and ''data'' (DATA type) vsegs, defining the process binary code and global data. The actual vsegs base addresses and sizes are defined in the .elf file and reported in the [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/tools/arch_info/boot_info.h boot_info_t] structure by the boot loader.
     210It contains the ''text'' (CODE type) and ''data'' (DATA type) vsegs, defining the user process binary code and global data. The actual vsegs base addresses and sizes are defined in the .elf file and reported in the [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/tools/arch_info/boot_info.h boot_info_t] structure by the boot loader.
    211211
    212212'''5.1.4 The ''heap'' zone'''