Rev 83 | Rev 96 | Go to most recent revision | Show entire file | Regard whitespace | Details | Blame | Last modification | View Log | RSS feed
Rev 83 | Rev 84 | ||
---|---|---|---|
Line 570... | Line 570... | ||
570 | TLB according to messages found in its TLB shootdown message queue. In |
570 | TLB according to messages found in its TLB shootdown message queue. In |
571 | the end, each processor sets its TLB flag and resumes its previous |
571 | the end, each processor sets its TLB flag and resumes its previous |
572 | operation.</para> |
572 | operation.</para> |
573 | </formalpara> |
573 | </formalpara> |
574 | </section> |
574 | </section> |
- | 575 | </section> |
|
575 | 576 | ||
576 | <section> |
577 | <section> |
577 | <title>Address spaces</title> |
578 | <title>Address spaces</title> |
578 | 579 | ||
579 | <section> |
- | |
580 | <indexterm> |
- | |
581 | <primary>address space</primary> |
580 | <para>last bits about address spaces</para> |
582 | - | ||
583 | <secondary>- area</secondary> |
- | |
584 | </indexterm> |
- | |
585 | - | ||
586 | <title>Address space areas</title> |
- | |
587 | - | ||
588 | <para>Each address space consists of mutually disjunctive continuous |
- | |
589 | address space areas. Address space area is precisely defined by its |
- | |
590 | base address and the number of frames/pages is contains.</para> |
- | |
591 | - | ||
592 | <para>Address space area , that define behaviour and permissions on |
- | |
593 | the particular area. <itemizedlist> |
- | |
594 | <listitem><emphasis>AS_AREA_READ</emphasis> flag indicates reading |
- | |
595 | permission.</listitem> |
- | |
596 | - | ||
597 | <listitem><emphasis>AS_AREA_WRITE</emphasis> flag indicates |
- | |
598 | writing permission.</listitem> |
- | |
599 | - | ||
600 | <listitem><emphasis>AS_AREA_EXEC</emphasis> flag indicates code |
- | |
601 | execution permission. Some architectures do not support execution |
- | |
602 | persmission restriction. In this case this flag has no |
- | |
603 | effect.</listitem> |
- | |
604 | - | ||
605 | <listitem><emphasis>AS_AREA_DEVICE</emphasis> marks area as mapped |
- | |
606 | to the device memory.</listitem> |
- | |
607 | </itemizedlist></para> |
- | |
608 | - | ||
609 | <para>Kernel provides possibility tasks create/expand/shrink/share its |
- | |
610 | address space via the set of syscalls.</para> |
- | |
611 | </section> |
- | |
612 | 581 | ||
613 | <section> |
582 | <section> |
614 | <indexterm> |
583 | <indexterm> |
615 | <primary>address space</primary> |
584 | <primary>address space</primary> |
616 | 585 | ||
617 | <secondary>- ASID</secondary> |
586 | <secondary>- ASID</secondary> |
618 | </indexterm> |
587 | </indexterm> |
619 | 588 | ||
620 | <title>Address Space ID (ASID)</title> |
589 | <title>Address Space ID (ASID)</title> |
621 | 590 | ||
622 | <para>Every task in the operating system has it's own view of the |
591 | <para>Modern processor architectures optimize TLB utilization by |
623 | virtual memory. When performing context switch between different |
592 | associating TLB entries with address spaces through assigning |
624 | tasks, the kernel must switch the address space mapping as well. As |
593 | identification numbers to them. In HelenOS, the term ASID, originally |
625 | modern processors perform very aggressive caching of virtual mappings, |
594 | taken from the mips32 terminology, is used to refer to the address space |
626 | flushing the complete TLB on every context switch would be very |
595 | identification number. The advantage of having ASIDs is that TLB does |
627 | inefficient. To avoid such performance penalty, some architectures |
596 | not have to be invalidated on thread context switch as long as ASIDs are |
628 | introduce an address space identifier, which allows storing several |
597 | unique. Unfotunatelly, architectures supported by HelenOS use all |
629 | different mappings inside TLB.</para> |
598 | different widths of ASID numbers<footnote> |
630 | - | ||
631 | <para>HelenOS kernel can take advantage of this hardware support by |
599 | <para>amd64 and ia32 don't use similar abstraction at all, mips32 |
632 | having an ASID abstraction. I.e. on ia64 kernel ASID is derived from |
600 | has 8-bit ASIDs and ia64 can have ASIDs between 18 to 24 bits |
- | 601 | wide.</para> |
|
633 | RID (region identifier) and on the mips32 kernel ASID is actually the |
602 | </footnote> out of which none is sufficient. The amd64 and ia32 |
634 | hardware identifier. As expected, this ASID information record is the |
603 | architectures cannot make use of ASIDs as their TLB doesn't recognize |
635 | part of <emphasis>as_t</emphasis> structure.</para> |
604 | such an abstraction. Other architectures have support for ASIDs, but for |
636 | - | ||
637 | <para>Due to the hardware limitations, hardware ASID has limited |
605 | instance ppc32 doesn't make use of them in the current version of |
638 | length from 8 bits on ia64 to 24 bits on mips32, which makes it |
606 | HelenOS. The rest of the architectures does use ASIDs. However, even on |
- | 607 | the ia64 architecture, the minimal supported width of ASID<footnote> |
|
- | 608 | <para>RID in ia64 terminology.</para> |
|
639 | impossible to use it as unique address space identifier for all tasks |
609 | </footnote> is insufficient to provide a unique integer identifier to |
640 | running in the system. In such situations special ASID stealing |
610 | all address spaces that might hypothetically coexist in the running |
641 | algoritm is used, which takes ASID from inactive task and assigns it |
611 | system. The situation on mips32 is even worse: the architecture has only |
642 | to the active task.</para> |
612 | 256 unique identifiers.</para> |
643 | 613 | ||
644 | <indexterm> |
614 | <indexterm> |
645 | <primary>address space</primary> |
615 | <primary>address space</primary> |
646 | 616 | ||
647 | <secondary>- ASID stealing</secondary> |
617 | <secondary>- ASID stealing</secondary> |
648 | </indexterm> |
618 | </indexterm> |
649 | 619 | ||
- | 620 | <para>To mitigate the shortage of ASIDs, HelenOS uses the following |
|
650 | <para> |
621 | strategy. When the system initializes, a FIFO queue<footnote> |
651 | <classname>ASID stealing algoritm here.</classname> |
622 | <para>Note that architecture-specific measures are taken to avoid |
- | 623 | too large FIFO queue. For instance, seven consecutive ia64 RIDs are |
|
652 | </para> |
624 | grouped to form one HelenOS ASID.</para> |
- | 625 | </footnote> is created and filled with all available ASIDs. Moreover, |
|
- | 626 | every address space remembers the number of processors on which it is |
|
- | 627 | active. Address spaces that have a valid ASID and that are not active on |
|
- | 628 | any processor are appended to the list of inactive address spaces with |
|
- | 629 | valid ASID. When an address space needs to be assigned a valid ASID, it |
|
- | 630 | first checks the FIFO queue. If it contains at least one ASID, the ASID |
|
- | 631 | is allocated. If the queue is empty, an ASID is simply stolen from the |
|
- | 632 | first address space in the list. In that case, the address space that |
|
- | 633 | loses the ASID in favor of another address space, is removed from the |
|
- | 634 | list. After the new ASID is purged from all TLBs, it can be used by the |
|
- | 635 | address space. Note that this approach works due to the fact that the |
|
- | 636 | number of ASIDs is greater than the maximal number of processors |
|
- | 637 | supported by HelenOS and that there can be only one active address space |
|
- | 638 | per processor. In other words, when the FIFO queue is empty, there must |
|
653 | </section> |
639 | be address spaces that are not active on any processor.</para> |
654 | </section> |
640 | </section> |
655 | </section> |
641 | </section> |
656 | </chapter> |
642 | </chapter> |
657 | 643 |