Em todas as causas get-empty-pgtable ( ) é chamada primeiro para assegurar a existência de uma page table que cobre o endereço falatando. No terceiro para providenciar uma página no endereço requerido e no caso de uma página trocada, swap-in ( ) é chamado. No segundo caso, o handles calls share-page ( ) para ver se a página pode ser dividida com algum outro processo. Se isto falhar leia a página do executável ou biblioteca (Isto repete a chamada para Share-page ( ) se um outro processo fez o mesmo enquanto isso). Qualquer porção da página fora do valor brK é zerada. A página lida do disco é contada como um erro maior. Isto acontece com um swap-in ( ) ou quando é lida da executável ou uma biblioteca. Outras casos são consideradas erros menores (mim-flt). Quando uma página divisível é achada ela é corite-protected. Um processo que escreve para uma página dividida vai precisar passar por um do-wppage ( ) que faz o copy-on-write. Do-wp-page ( ) faça o seguinte:
•Mande SIGSEGV se qualquer usar process o está escrevendo para o corrente code-space.
•Se a página velha não é dividida, então simplesmente não proteja-o. Senão get-free-page ( ) and copy-page ( ). A página adquirire a bandeira suja da página velha. Diminua a conta do mapa da página velha.
4.6 - Paginando (Paging)
Paginando é a troca numa base da página melhor do que os processos inteiros. Nós vamos usar trocando aqui para referir à "paginando" , uma vez que apenas Linux página, e não trocar, e pessoas são mais acostumadas à palavra "Swap" / "trocar" do que "page" / "paginar". Kernel pages nunca são trocadas páginas limpas também não são escritas para trocar. Elas são liberadas e recarregadas quando é requerida. O trocador mantém um único bit de informação de envelhecimento nas Páginas acessadas bit da page table cutries - [ O que são os detalhes de manutenção? Como isto é usado?]
Linux suporta múltiplos swap files ou projetos que podem ser ligados ou desligados pelas ligações de swapoff system. Cada swap file ou projeto é descrito por uma strut-swap-info.
O campo das bandeiras (SWP-USED ou SWP-WRITE ok) é usado para controlar acesso para o swap files. Quando SWP- WRITE ok é desligado, o espaço não vai ser distribuído neste arquivo. Isto é usado por Swapoff quando isto tenta de não usar um arquivo. Quando swapoff adiciona um arquivo de troca nova isto aplica SWP-USED. Um variável imóvel no Swap files armazena o número dos arquivos ativos correntemente ativos. Os campos lowest - bit e hihgest - bit limitam a região livre na pasta de troca e são usadas para adiantar a procura por espaço de troca livre.
O programa do usuário m | < swap inicializa um swap device ou file. A primeira página contém uma assinatura (swap-space) nos últimos 10 bytes, e contém um mapa de bit. Inicialmente 1's no bitmap significam páginas ruins A'1' no bitmap significa que a página correspondente é livre. Esta página nunca é distribuída deste modo a inicialização precisa ser feita somente uma vez.
The Syscall Swapor ( ) é chamado pelo user program swapon tipicamente de / etc / rc. Algumas páginas da memória são distribuídas por swap-map e swap-lockmap, swap-map contém um byte para cada página no swapfile. Isto é inicializado do bitmap para conter 0 para páginas disponíveis e 128 para páginas que não pode ser usadas. Isto é para manter uma conta das petições da troca em cada página no swap file. Swap-lockmap contém um bit para cada página que é usada para assegurar exclusão mútua quando lendo ou escrevendo swap-files.
Quando uma página da memória está para ser trocada, um índice para posição da troca é obtido com uma chamada para getswap-page ( ). Este índice é deste modo guardado em bits 1-31 da page table entry para que a página trocada possa ser localizada pela page fault handles, do-no-page ( ) quando necessário.
Os 7 bits mais altos do índice dão o swap file ( ou projeto) e os 24 bits mais baixos dão o número da página neste projeto. Isto faz até 128 swap files, cada um com espaço para mais ou menos 64 Gb, mas o espaço em cima devido o swap map seria grande. Ao invés o tamanho do swap file é limitado para 16 Mb, porque o swap map então toma 1 página. A função swap-duplicate ( ) é usado por copy-page-tables ( ) para deixar o processo da child herdar páginas trocadas durante um fork. Isto somente incrementa a conta mantendo no Swap-map para aquela página. Cada processo vai trocar numa cópia da página separa quando acessá-la. Swap-free diminui a conta mantendo no swap-map. Quando a conta abaixa para 0 a página pode ser redistribuída por getswap-page ( ). Isto é chamado cada vez que uma página trocada é lida na memória ( swap-inc ) ou quando uma página está para ser descartada ( free-one-table ( ), etc ).
4.7 - Gerenciamento de Memória Cache
4.7.1 - Arquitetura de Memória Cache do Linux (Linux Flush Architecture)
O TBL é mais uma entidade virtual do que um modelo estrito quanto a Linux flush architecture e concernida. As característica única são isto mantem em ordem o mapeamento do processo kernel de algum modo, queira softivare ou hardware.
Código específico de arquitetura pode precisar ser modificado quando o kernel tiver mudado um processo/mapeamento kernel.
O shell (um lugar seguro p/ guardar dinheiro ou coisas) esta entidade é essencialmente "memory state"/"estado da memoria" como o flush architecture o vê. Em geral isto tem as propiedades seguintes:
•Isto sempre vai segurar cópias de dados que podem ser visto como atualizado pelo processo local.
•O funcionamento próprio pode ser relacionado ao TLB e o mapeamento do processo/Kernel page de algum jeito, isto é para dizer que eles podem depender um do outro.
•Isto pode, numa configuração cached virtual, causar problemas "aliasing" se uma página fisica é mapeada no mesmo tempo da que duas páginas virtuais e por causa dos bits de um endereço usado para catalogar a linha cache, a mesma porção do dedo pode acabar residindo no cache duas vezes, deixando resultados incompativéis.
•Projetos e DMA podem ou não ter capacidade para ver a cópia de um dedo mais atualizado que resida no cache do processo local.
•Corretamente, é suposto que a coerência num ambiente multiprocessador é mantida pelo subsistema cache/memória. Isto que dizer que, quando um processador requerer um dado no memory bus de maneira e um outro processador tem uma cópia mais atualizada, de qualquer jeito o requesitor vai obter uma cópia atualizada que pertença um outro processador.
(NOTA: SMP arquiteturas sem hardware cache conferece mechanísms são realmente possíveis, o arquitetura current flush não sustenta isto corretamente, se em algum ponto o Zinux apontar em algum sistema onda isto é uma questão debatida, eu vou adicionar os ganchos necessários mas não vai ser bonito)
Sobre o que o Fluch Architecture se importa: sempre, a visão da administração de memória hardware de um conjunto de mapeamento do processo Kernel serão consistentes com aqueles do Kernel page tables.
Se o memory managemat kernel code faz uma modificação para a user process page modificando o dado via kernel space alias da página física subjacente, o fio controle de usuário vai ser o dado correto antes que é permitido continuar a execução, indiferente da cache architecture e/ou a semântica.
Em geral, quando o estado do espaço de endereço é mudado somente (em código genérico da administração da memória kernelnome de generic kernel management cade) o fluch architecture hook apropriado vai ser chamado descrevendo que o estado muda totalmente.
Sobre o que o flush architecture não importa: que o mapeamento do DMA "DMA/driver coerência. Isto inclui DMA mappings (no sentido do MMU mappings) e o cache/DMA dado consistência. Estes tipos des assuntos não devem esta no flush architecture, veja embaixo como eles devem ser manuseados.
Split Instrution/data cache consistência com respeitro as modificações feito para processo de instrução de espaço realizado pelo código de sinal de despacho signal dispatch cade. De novo, veja embaixo como isto devem ser manuseado de um outro jeito.
As interfaces para a flushachitesture e como executá-los em geral todas as rotinas descritos embaixo vão ser chamados na sequência seguinte: Fluch-cache-foo(...); modify-address-space (); clush - tlb-foo (...) a lógica aqui é: Isto pode ser ilegal num arquitetura dada por um pedaço de dado cache para ensitir quando o mapeamento por aquele dado não existe, portanto o flush deve ocorrer antes que a mudança é feita.
É possivél para uma arquitertura de MMU/TLB dada realizar um andamento da tabela hardware hardware table wolk dos kernel page tables, portanto o TLV flush é feito depois que os page tables terem sido mudados para que depois o hardware só pode carregar a cópia nova da informação de page table para o TLB void flush - cache - all (void); void flush - tlb - all (void);
Essas rotinas são para notificar o architecture specific cade que mapeamento do espaço do endereço kernel uma mudança foi feita ao kernel address space mappings, que significa que os mapeamentos de todos processos foram efetivamente mudados.
4.7.2 - Implementação da Memória Cache
Uma implementação deve:
•Eliminar todos os entradas do cache que são válidas neste momento quando flush-cache-all é invocado isto refere-se ao virtual cache architecture, se a cache is write-back, essa rotina vai submeter o dado da cache para memoria antes do que invalidar cada ingresso. Para caches físicos, não é necessário realizar uma ação já que mapeamento físico não tem ponto de apoio no address space translations.
•Para flush-tlb-all todos TLB mappings para o kernel address space devem ser feito consitente com os OS page tables de qualquer maneira. Norte que com um arquitetura que possua a nação
•Para flush-tlb-m, o tlb/mu hardware é para estar localizado num estado onde isto vai ver (agora corrente) kernal page table entradas para o espaço de endereço pelo m-strust.
flush_cache_range(struct m_struct *m, unsigned long start, unsigned long end); flush_tlb_range(struct m_struct *m, unsigned long start, unsigned long end); uma chance para uma particular range do user address no adelrass space descrito pelo m-struct passada esta ocorrendo. As duas notas acima para FLUSH - m( ) relecianando a m-struct passada aplicam-se aqui também.
•Para Flush-cache-range num virtualmente cached system, todas entradess cache que são nolidas pena a range partem para o fim no address space descrito pelo m-struect são para ser invalidadas.
•Para Flush-tlb-range, qualquer ação necessária para causar o
MMUITLB hardware não conter traduções estragados são para ser realizados. Isso significa que quaiquer traduções estão no Kernel page tables no range start para acabar no address space descrito pelo m-struet são para que a administração da memoria hardware sera deste ponto avançado, por qualquer significado.
void flush_cache_page(struct vm_area_struct *vma, unsigned long address); void flush_tlb_page(struct vm_area_struct *vma, unsigned long address);
Uma chance para uma única página no address dentro do usar space para o address space descrito pelo um area-struet passado esta ocorrendo. Uma efetivação, se necessária, pode obter na m-struet associado para este address space via uma um - Flags. Este caminho em uma efetivação onde a instrução e dara space não são unificados, alguem pode conferir para ver se um-exee esta posto no uma-sumflags para possivelmente avistar flushing o instruction space, por exemplos: As duas notas acima para flush-*-m( ) concermindo o m-struct (passado indiretamente via uma -um-m) aplica aqui também.
A implemetação deve também :
•Para flush-cache-range, num virtualmente cache systam, todas entradas cacha que são validas para a página no addrees no address space descrito pelo uma são para ser invalidados.
MMU/TLB hardware para não conter traduções estragadas são para ser efetuadas. Isto significa que quaisquer traduções estão nos kernel page tables para a página no address space descrito pelo uma passado são para que a administração de memória hardware, serão vistas deste ponto avançado de qualquer maneira.
4.7.3 - Carregando o Flush-PAGE para a RAM (Unsigned Long Page);
Este é o patinho feio. Mas sera semântica é necessário em muitas arquiteturas que precisei para adicionar isto apra a arquitetura flush para linux. Brevemente, quando (como um exemplo) serve um kernel um enode cow, isto usa o "suposto" mapeamento de todas memorias fisicas no espaço kernal para efetuar a cópia da página em questão para uma nova página. Este apresenta um problema para caches virtualmente catalogados que são write-back escritos de volta na natureza. Neste caso, o Kernel toca duas páginas fisicas no espaço Kernel. A sequencia do código sendo descrito aqui essencialmente parece como:
do_wp_page() { copy_cow_page(old_page,new_page); flush_page_to_ram(old_page); flush_page_to_ram(new_page); flush_cache_page(vma, address);