Changes between Version 38 and Version 39 of WikiStart


Ignore:
Timestamp:
Jan 17, 2017, 1:02:54 PM (7 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • WikiStart

    v38 v39  
    2929This section describes the general assumptions made by ALMOS-MK regarding the hardware architecture, and the mechanism to configure ALMOS-MK for a given target architecture.
    3030
     31== B) [wiki:processus_thread Process & threads creation/destruction] ==
    3132
     33ALMOS-MK supports the POSIX threads API. In order to avoid contention in massively multi-threaded applications, ALMOS-MK replicates the user process descriptors in all clusters containing threads of this process. This section describes the mechanisms for process and thread creation / destruction.
    3234
    33 == B) [wiki:replication_distribution Data replication & distribution policy] ==
     35== C) [wiki:replication_distribution Data replication & distribution policy] ==
    3436
    3537This section describes the general policy for replication/distribution of the informations on the various physical memory banks.
    3638We have two main goals: enforce memory access locality, and avoid contention when several threads access simultaneously the same information. To control the placement and the replication of the physical memory banks, the kernel uses the paged virtual memory.
    3739
    38 == C) [wiki:page_tables Distributed Pages Tables] ==
     40== D) [wiki:page_tables GPT & VSL implementation] ==
    3941
    40 To avoid contention when several threads access the same page table to handle TLB miss, ALMOS-MK replicates the page tables. For each multi-threaded user application P, the page table and the list of virtual segments (implemented in the Virtual Memory Manager) are replicated in each cluster K containing at least one thread of the application. According to the "on-demand paging" principle, these replicated page tables GPT(K,P) and  virtual segment lists VSL(K,P) are dynamically updated when page faults are detected. This section describes this building mechanism and the coherence protocol required by these multiple copies.
     42To avoid contention when several threads access the same page table to handle TLB miss, ALMOS-MK replicates the page tables. For each multi-threaded user application P, the Generic Page Table (GPT), and the Virtual Segments List (VSL) are replicated in each cluster K containing at least one thread of the application. According to the "on-demand paging" principle, these replicated structures GPT(K,P) and VSL(K,P) are dynamically updated when page faults are detected. This section describes this building mechanism and the coherence protocol required by these multiple copies.
    4143
    42 == D) [wiki:processus_thread Process & threads creation/destruction] ==
     44== E) [wiki:thead_scheduling Trans-Cluster lists of threads] ==
    4345
    44 ALMOS-MK supports the POSIX threads API. In order to avoid contention in massively multi-threaded applications, ALMOS-MK replicates the user process descriptors in all clusters containing threads of this process. This section describes the mechanisms for process and thread creation / destruction.
    45 
    46 == E) [wiki:thead_scheduling Threads scheduling] ==
    47 
    48 Dans ALMOS, on utilise des listes doublement chaînées ''internes'' pour représenter l'ensemble des thread en attente d'une même ressource.
    49 Ces listes doivent être  modifiées à chaque opération d'ordonnancement qui modifie l'état d'un thread. Puisque les thread d'une même application parallèle multi-thread peuvent être distribués sur tous les clusters de l'architecture, ces files d'attentes sont donc ''trans-cluster'', ce qui est contradictoire avec la politique multi-kernel d'ALMOS-MK. Cette section analyse le problème et propose différentes solutions.
     46ALMOS_MK uses double linked list to represent  a set of threads. For example ALMOS-MK must build the set of all threads waiting to access a given resource, such as a given peripheral device.
     47As these threads can be running on any cluster, these linked lists are ''trans-cluster'', and requires specifictechnics in a multi kernel OS, where each kernel instance is handling only resources localized in a single cluster.
    5048
    5149== F) [wiki:rpc_implementation Communication par RPC] ==