Subversion Repositories HelenOS-doc

      linkend="Black89" />. </para>

      linkend="Black89" />.</para>

      <title>Address spaces</title>

      <title>Address Space ID (ASID)</title>

          <primary>address space</primary>

      <para>Modern processor architectures optimize TLB utilization by

          <secondary>- area</secondary>

      associating TLB entries with address spaces through assigning

        <title>Address space areas</title>

      identification numbers to them. In HelenOS, the term ASID, originally

        <para>Each address space consists of mutually disjunctive continuous

      taken from the mips32 terminology, is used to refer to the address space

        address space areas. Address space area is precisely defined by its

      identification number. The advantage of having ASIDs is that TLB does

        base address and the number of frames/pages is contains.</para>

      not have to be invalidated on thread context switch as long as ASIDs are

        <para>Address space area , that define behaviour and permissions on

      unique. Unfotunatelly, architectures supported by HelenOS use all

        the particular area. <itemizedlist>

      different widths of ASID numbers<footnote>

            <listitem><emphasis>AS_AREA_READ</emphasis> flag indicates reading

          <para>amd64 and ia32 don't use similar abstraction at all, mips32

            <listitem><emphasis>AS_AREA_WRITE</emphasis> flag indicates

          has 8-bit ASIDs and ia64 can have ASIDs between 18 to 24 bits

            writing permission.</listitem>

          wide.</para>

            <listitem><emphasis>AS_AREA_EXEC</emphasis> flag indicates code

        </footnote> out of which none is sufficient. The amd64 and ia32

            execution permission. Some architectures do not support execution

      architectures cannot make use of ASIDs as their TLB doesn't recognize

            persmission restriction. In this case this flag has no

      such an abstraction. Other architectures have support for ASIDs, but for

            effect.</listitem>

      instance ppc32 doesn't make use of them in the current version of

            <listitem><emphasis>AS_AREA_DEVICE</emphasis> marks area as mapped

      HelenOS. The rest of the architectures does use ASIDs. However, even on

            to the device memory.</listitem>

      the ia64 architecture, the minimal supported width of ASID<footnote>

          </itemizedlist></para>

          <para>RID in ia64 terminology.</para>

        <para>Kernel provides possibility tasks create/expand/shrink/share its

        </footnote> is insufficient to provide a unique integer identifier to

        address space via the set of syscalls.</para>

      all address spaces that might hypothetically coexist in the running

      </section>

      256 unique identifiers.</para>

        <indexterm>

      <indexterm>

          <primary>address space</primary>

        <primary>address space</primary>

          <secondary>- ASID</secondary>

        <secondary>- ASID stealing</secondary>

        </indexterm>

      </indexterm>

        <title>Address Space ID (ASID)</title>

      <para>To mitigate the shortage of ASIDs, HelenOS uses the following

        <para>Every task in the operating system has it's own view of the

      strategy. When the system initializes, a FIFO queue<footnote>

        virtual memory. When performing context switch between different

          <para>Note that architecture-specific measures are taken to avoid

        tasks, the kernel must switch the address space mapping as well. As

          too large FIFO queue. For instance, seven consecutive ia64 RIDs are

        modern processors perform very aggressive caching of virtual mappings,

          grouped to form one HelenOS ASID.</para>

        flushing the complete TLB on every context switch would be very

        </footnote> is created and filled with all available ASIDs. Moreover,

        inefficient. To avoid such performance penalty, some architectures

      every address space remembers the number of processors on which it is

        introduce an address space identifier, which allows storing several

      active. Address spaces that have a valid ASID and that are not active on

        <para>HelenOS kernel can take advantage of this hardware support by

      any processor are appended to the list of inactive address spaces with

        having an ASID abstraction. I.e. on ia64 kernel ASID is derived from

      valid ASID. When an address space needs to be assigned a valid ASID, it

        RID (region identifier) and on the mips32 kernel ASID is actually the

      first checks the FIFO queue. If it contains at least one ASID, the ASID

        hardware identifier. As expected, this ASID information record is the

      is allocated. If the queue is empty, an ASID is simply stolen from the

        part of <emphasis>as_t</emphasis> structure.</para>

      first address space in the list. In that case, the address space that

        <para>Due to the hardware limitations, hardware ASID has limited

      loses the ASID in favor of another address space, is removed from the

        length from 8 bits on ia64 to 24 bits on mips32, which makes it

      list. After the new ASID is purged from all TLBs, it can be used by the

        impossible to use it as unique address space identifier for all tasks

      address space. Note that this approach works due to the fact that the

        running in the system. In such situations special ASID stealing

      number of ASIDs is greater than the maximal number of processors

        algoritm is used, which takes ASID from inactive task and assigns it

      supported by HelenOS and that there can be only one active address space

          <secondary>- ASID stealing</secondary>

      per processor. In other words, when the FIFO queue is empty, there must

          <classname>ASID stealing algoritm here.</classname>

      be address spaces that are not active on any processor.</para>